| From: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, 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:28:20 |
| Message-ID: | 20141203192820.GL10679@aart.rice.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 03, 2014 at 02:08:27PM -0500, Tom Lane wrote:
> 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
>
Or between a node with a low rows count and a high rows count for those
pesky mis-estimation queries.
Regards,
Ken
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2014-12-03 19:29:37 | Re: Removing INNER JOINs |
| Previous Message | Alvaro Herrera | 2014-12-03 19:25:51 | Re: pgsql: Keep track of transaction commit timestamps |