> On 23 Feb 2026, at 21:54, Laurenz Albe <[email protected]> wrote: >>> The difference in the plans is under the "Subquery Scan on odg", starting >>> with >>> plan node 50 (everything under the "Sort"). I suspect that the mis-estimate >>> that is at the root of the problem is here: >>> >>> -> Index Scan using table_k_late_spec_dp_end_dat_key on schema1.table_k >>> kal (... rows=196053 ...) (... rows=471.00 ...) >>> Index Cond: (kal.dp_end_dat < ('now'::cstring)::date) >>> Index Searches: 1 >>> Buffers: shared hit=230 read=49 >>> I/O Timings: shared read=0.142 >>> >>> PostgreSQL overestimates the row count by a factor of over 400. >>> Try to fix that estimate and see if that gets PostgreSQL to do the right >>> thing. >>> >>> Perhaps a simple ANALYZE on the table can do the trick. >> >> >> In the examples I used table_k to flip the plan with >> vacuum -Upostgres -vZ -t schema1.tbl_used_in_query db1 >> in the explain output schema1.tbl_used_in_query is table_k > > I cannot understand that.
sorry for being unclear. To "switch" between the ok and wrong plans I execute vacuumdb -Upostgres -vZ -t schema1.table_k db1 multiple times (1x-3x) until the plan flips. So I thought the table should already have been analyzed. In my first email I called table_k as the "tbl_used_in_query" or have I misunderstood that with the analyze? Thanks Regards, Attila
