i_have_to_speak
Joined 13 years ago
Karma
639
Submissions
277
Member since
Sep 8
Recent submissions
Comment · 7 months ago
TBF that is an isolated incident, not a distinguishing trait of a species.
Comment · 7 months ago
Are homo sapiens the only species that organizes themselves into tribes and work towards the destruction of other tribes of same species?
Comment · 7 months ago
This is a great initiative. Benchmarking managed services is notoriously tricky due to varying configurations and 'black-box' optimizations. For anyone looking to run these benchmarks on their own or wanting to dive deeper into the why behind the numbers, pgmetrics (https://pgmetrics.io) is a fantastic open-source tool. It collects a massive amount of internal PG stats into a structured JSON format, making it easy to see exactly what's happening during a load test. For a more persistent and visual way to track these metrics across different providers, pgDash (https://pgdash.io) is built on top of that same data.
Comment · 7 months ago
Great write-up—the distinction between healthy OS caching and actual memory pressure is often misunderstood. To get a granular view of where your memory is actually going (shared buffers, cache hits, etc.) without the overhead of heavy agents, pgmetrics (https://pgmetrics.io) is very effective. If you need to track these metrics over time to catch when 'good' caching turns into 'bad' pressure, pgDash (https://pgdash.io) builds directly on top of it to provide a specialized monitoring dashboard with zero-config setup.
Comment · 7 months ago
This looks like a great addition to the Postgres ecosystem. When adding specialized extensions like this, it's always worth keeping an eye on how they impact overall system performance, especially memory usage and lock contention as the dataset grows. For anyone testing this out, I'd recommend using an open-source tool like *pgmetrics* (https://pgmetrics.io) to get a baseline and then monitor how the new indexes and search workloads affect your underlying metrics. It’s zero-dependency and gives you a very deep look into the internals without much overhead.
Comment · 9 months ago
You might like this static full year planner version: https://pgdash.io/2026
Comment · 1 year ago
Is there an index of all these pages?
Comment · 1 year ago
This really has nothing to do with CTEs.
The SQL standard does not specify how many times a subquery must or can be run. In this case, Postgres is free to run the uncorrelated subquery many times. Unfortunately, the subquery result is not idempotent.
The real solution is not to rely on the optimizer for the correctness of your query. The query should be logically correct, irrespective of the query plan, right? The correct solution would be to ensure that the subquery runs only once, using a materialized cte or temp table. Do not base your "solution" on the discovery that for this particular version of Postgres, the planner runs this type of subquery once for the '=' operator and multiple times for 'IN'.