| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Arne Roland <A(dot)Roland(at)index(dot)de> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Disabling options lowers the estimated cost of a query |
| Date: | 2021-02-26 03:00:18 |
| Message-ID: | 219912.1614308418@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Arne Roland <A(dot)Roland(at)index(dot)de> writes:
> I want to examine the exhaustive search and not the geqo here. I'd expect the exhaustive search to give the plan with the lowest cost, but apparently it doesn't. I have found a few dozen different querys where that isn't the case. I attached one straight forward example. For the join of two partitions a row first approach would have been reasonable.
Hmm. While the search should be exhaustive, there are pretty aggressive
pruning heuristics (mostly in and around add_path()) that can cause us to
drop paths that don't seem to be enough better than other alternatives.
I suspect that the seqscan plan may have beaten out the other one at
some earlier stage that didn't think that the startup-cost advantage
was sufficient reason to keep it.
It's also possible that you've found a bug. I notice that both
plans are using incremental sort, which has been, um, rather buggy.
Hard to tell without a concrete test case to poke at.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jung, Jinho | 2021-02-28 15:04:33 | Potential performance issues |
| Previous Message | Justin Pitts | 2021-02-26 01:06:15 | Re: Postgres performance comparing GCP and AWS |