Follow your suggestion to increase statistics_target (I increase
target_statistic to 1000 for aa.mmm_id and cc.sss_id ,analyze tablea,
tablec again), optimizer choose the good SQL plan.
Thanks,
James
Andrei Lepikhov 於 2025年4月3日週四 下午4:44寫道:
> On 4/3/25 10:04, James Pang wrote:
> > one more
On 4/3/25 02:46, James Pang wrote:
Andrei,
Yes, from explain output, since optimizer already get the
merge_append cost but not take account into total cost, that make a big
difference. I shared table DDLs and explain analyze,buffers output , I
think the data maybe generated by other way
Andrei,
Yes, from explain output, since optimizer already get the merge_append
cost but not take account into total cost, that make a big difference. I
shared table DDLs and explain analyze,buffers output , I think the data
maybe generated by other way to reproduce this issue. sorry for not sh
On 4/2/25 12:18, James Pang wrote:
Hi,
Postgresq v14.8, we found optimizer doest not take "merge append"
cost into sql plan total cost and then make a bad sql plan. attached
please find details.
I suppose there is a different type of issue.
MegeJoin sometimes doesn't need to scan the whole