[PERFORM] Fwd: Stalled post to pgsql-performance

Hi Karl and Jeff, On 26 June 2017 at 22:22, Jeff Janes wrote: > Be warned that "explain (analyze)" can substantially slow down and distort > this type of query, especially when sorting. You should run "explain > (analyze, timing off)" first, and then only trust "explain (analyze)" if > the over

Re: [PERFORM] Fwd: Slow query from ~7M rows, joined to two tables of ~100 rows each

Hi Karl, Thanks for the quick reply! Answers inline. My starting point, having executed exactly the preparation query in my email, was that the sample EXPLAIN (ANALYZE, BUFFERS) SELECT query ran in 15.3 seconds (best of 5), and did two nested loops . On 24 June

[PERFORM] Fwd: Slow query from ~7M rows, joined to two tables of ~100 rows each

Dear pgsql-performance list, I think I've found a case where the query planner chooses quite a suboptimal plan for joining three tables. The main "fact" table (metric_value) links to two others with far fewer rows (like an OLAP/star design). We retrieve and summarise a large fraction of rows from