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
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.
Query: masking table and column names :
select
from tablea aa
inner join tableb bb on aa.ind1 = bb.ind1
inner joi
