lfittl

20 ms·

1.
by lfittl 1mo ago
5 mins of Postgres! I still do them occasionally, but its hard to find the time currently. Glad to hear you liked them :)
2.
by lfittl 1mo ago
pganalyze | Marketing Manager | REMOTE (US) | Full-time | base $130-160k + annual bonus + equity | https://pganalyze.com At pganalyze, we build observability and automation tools for optimizing the performance of Postgres databa
3.
by lfittl 2mo ago
My assumption is that its based on that repo but with the "ee/" folder removed, per https://github.com/PostHog/posthog#open-source-vs-paid Presumably so folks can be sure they're not accidentally pu
4.
by lfittl 3mo ago
I don't think Tom's perspective has necessarily changed (and there is certainly concern from others that this could cause less reports on planner bugs), but Tom is pretty good about not standing in the way of others (i.e. Robert H
5.
by lfittl 3mo ago
Its also worth reading the original post by Robert Haas (the author of pg_plan_advice) on motivation/design: https://rhaas.blogspot.com/2026/03/pgplanadvice-plan-stabili... Also, I'll add my perspective:
6.
by lfittl 5mo ago
The original author of pgBackRest posted on LinkedIn today that he will very likely revive the project, given the interest and new sponsorship opportunities: https://www.linkedin.com/feed/update/urn:li:activity:745
7.
PostgreSQL and the OOM Killer: Why We Use Strict Memory Overcommit(ubicloud.com)
3 points by lfittl 5mo ago|0 comments
8.
Waiting for Postgres 19: Reduced Timing Overhead for EXPLAIN ANALYZE with RDTSC(pganalyze.com)
2 points by lfittl 5mo ago|0 comments
9.
by lfittl 6mo ago
Its worth reading this follow-up LKML post by Andres Freund (who works on Postgres): https://lore.kernel.org/lkml/yr3inlzesdb45n6i6lpbimwr7b25kqk...
10.
by lfittl 7mo ago
Thanks for posting! There is a hand-edited transcript here as well, for those who prefer text: https://pganalyze.com/blog/5mins-postgres-19-better-planner-... And, its noted in the video/transcript, but for clarit
11.
by lfittl 7mo ago
Specifically on the cost of forking a process for each connection (vs using threads), there are active efforts to make Postgres multi-threaded. Since Postgres is a mature project, this is a non-trivial effort. See the Postgres wiki for some
12.
by lfittl 8mo ago
Since there seems to be some confusion in the comments about why pg_query chose Protobufs in the first place, let me add some context as the original author of pg_query (but not involved with PgDog, though Lev has shared this work by email
13.
by lfittl 9mo ago
Regarding pgstattuple specifically: If this was a 24/7/365 service and you would be concerned by the I/O impact of loading the full table or index at any time, you could run this on a replica too. For tables there is pgstattu
14.
by lfittl 9mo ago
I think there are two aspects to that: 1) When do pages get removed? (file on disk gets smaller) Regular vacuum can truncate the tail of a table if those pages at the end are fully empty. That may or may not happen in a typical workload, an
15.
by lfittl 9mo ago
The article has a section where it estimates index bloat based on comparing the number of index reltuples * 40 bytes (?), compared to the size of the file on disk. This is problematic, first of all because I don't think the math is rig
16.
by lfittl 1y ago
Yep, I find cloud storage performance to be quite frustrating, but its the reality for many production database deployments I've seen. Its worth noting that even on really fast local NVMe drives the new asynchronous I/O work deliv
17.
by lfittl 1y ago
It depends on the I/O method - as described in the article, "io_uring" is only available on Linux (and requires building with liburing, as well as io_uring to be enabled in the Kernel), but the default (as of beta1) is actual
18.
Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O(pganalyze.com)
572 points by lfittl 1y ago|154 comments
19.
by lfittl 1y ago
Thanks, glad to hear! I like to think that one of the reasons pganalyze is a good product (though there are always parts I'd like to improve, and feedback is always welcome) is because we like to use it ourselves to optimize our own da
20.
by lfittl 1y ago
Yeah, as one of the main authors of libpg_query, I think the primary things that make this easier is that Postgres has good abstractions internally, and the parser works independently from other parts (e.g. the community discourages adding
21.
by lfittl 1y ago
pganalyze | Senior Solutions Engineer | REMOTE (US/Canada) | Full-time | $160-200k + equity | https://pganalyze.com At pganalyze, we're redefining how developers optimize one of the world's most popular databases,
22.
by lfittl 2y ago
pganalyze | Senior Product Engineer | REMOTE (US/Canada) | Full-time | $160-200k + equity | https://pganalyze.com At pganalyze, we're redefining how developers optimize one of the world's most popular databases, P
23.
by lfittl 2y ago
pganalyze | Senior Product Engineer, Senior Solutions Engineer | REMOTE (US/Canada) | Full-time | https://pganalyze.com At pganalyze, we're redefining how developers optimize one of the world's most popular databa
24.
by lfittl 2y ago
In my understanding it was a timing issue with the UUIDv7 RFC not being finalized before the Postgres 17 feature freeze in early April. Shouldn't be an issue to get this in for Postgres 18, I think.
25.
Constraint Programming in Action: Optimizing Postgres Index Selection(pganalyze.com)
2 points by lfittl 2y ago|0 comments
26.
A practical introduction to constraint programming using CP-SAT and Python(pganalyze.com)
254 points by lfittl 2y ago|39 comments
27.
by lfittl 2y ago
Commenting on this a bit late, but in case anyone reads this later too: UUIDv7 support unfortunately didn't make it to Postgres 17, since the RFC wasn't completely finalized yet by the time of feature freeze (April 8), see discuss
28.
by lfittl 2y ago
Yep, there is a "link to video" link on the talk page - here is the direct link: https://www.youtube.com/watch?v=pGN_pORKtSQ We also did a more recent webinar that has some slight revisions on top of that talk, re
29.
by lfittl 2y ago
Thanks for the kind words! For anyone interested in how pganalyze's approach compares to this extension (and other alternatives like dexter, or using HypoPG directly), I gave a talk with my colleague Philippe last year at PgCon that de
30.
by lfittl 3y ago
Good point - its set up this way since we intentionally don't syndicate the 5mins of Postgres episodes to Planet Postgres, but I could see the benefit of having a complete feed that includes everything, for those subscribing via RSS re

More ›