| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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: | 2015-01-12 22:29:46 |
| Message-ID: | 54B44ADA.9000203@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/3/14 1:08 PM, 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.
In the interest of keeping the first pass simple... what if there was simply a switch node in front of every join that could be removable? That means you'd still be stuck with the overall plan you got from not removing anything, but simply eliminating the access to the relation(s) might be a big win in many cases, and presumably this would be a lot easier to code.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2015-01-12 22:39:47 | Re: WITH CHECK and Column-Level Privileges |
| Previous Message | Stephen Frost | 2015-01-12 22:16:40 | Re: WITH CHECK and Column-Level Privileges |