| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | 陈列行 <2320415112(at)qq(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: redundant double negation prevents IN-subquery pull-up and causes a slower SubPlan |
| Date: | 2026-08-17 13:51:54 |
| Message-ID: | 742002.1786974714@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Just to make you aware, we don't claim to have implemented every
> possible optimisation in the query planner. If you want to work on any
> of the optimisations you've mentioned in the set of emails you just
> sent, please feel free. For this particular optimisation, I really
> doubt we'd ever do anything for that one case unless it happened to
> become optimised as a side-effect of something larger and more useful
> project.
To expand on what David said: every time we think about adding a new
optimization rule to the planner, we have to weigh the potential
benefit against the cost of making the checks (not to mention the
engineering effort to create and then maintain the code). The benefit
will accrue to some subset of queries, whereas the cost will be paid
by a larger set wherein we make some tests and find the change doesn't
apply. So it's going to be hard to convince us to take a patch if the
benefit only applies to queries that are visibly badly written.
> I'd probably classify this one as more useful to keep so that someone
> can prevent the planner from choosing a Semi Join plan. It seems akin
> to the "col + 0" trick to prevent index or statistics usage on col.
Yeah, there's also that. Somebody could be deliberately using a
pattern like this to prevent optimization, for reasons that seem
good to them.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-08-17 13:52:27 | macOS + gcc + meson + --werror is broken |
| Previous Message | Xuneng Zhou | 2026-08-17 13:51:15 | Re: Deadlock detector fails to activate on a hot standby replica |