| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Mart Kelder <mart(at)kelder31(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Removing INNER JOINs |
| Date: | 2014-12-03 19:08:27 |
| Message-ID: | 22157.1417633707@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> Do you need to plan for every combination, where some joins are removed
> and some are not?
I would vote for just having two plans and one switch node. To exploit
any finer grain, we'd have to have infrastructure that would let us figure
out *which* constraints pending triggers might indicate transient
invalidity of, and that doesn't seem likely to be worth the trouble.
> I hope the same mechanism could be used to prepare a plan for a query
> with parameters, where the parameters might or might not allow a partial
> index to be used. We have some smarts nowadays to use custom plans, but
> this could be better.
Interesting thought, but that would be a totally different switch
condition ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2014-12-03 19:25:51 | Re: pgsql: Keep track of transaction commit timestamps |
| Previous Message | Stefan Kaltenbrunner | 2014-12-03 18:34:32 | Re: pgsql: Keep track of transaction commit timestamps |