> On 23 Feb 2026, at 21:54, Laurenz Albe <laurenz.albe@cybertec.at> 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
