| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dilip kumar <dilip(dot)kumar(at)huawei(dot)com> |
| Subject: | Re: Allowing join removals for more join types |
| Date: | 2014-06-05 23:44:31 |
| Message-ID: | 27391.1402011871@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
>> A bit more crazy, but how about trying trying to plan joins with a added
>> one-time qual that checks the size of the deferred trigger queue? Then
>> we wouldn't even need special case plans.
> That, too, sounds promising to investigate.
Not terribly. You can't actually do join removal in such a case, so it's
not clear to me that there's much win to be had. The planner would be at
a loss as to what cost to assign such a construct, either.
Moreover, what happens if the trigger queue gets some entries after the
query starts?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2014-06-06 00:08:32 | Why is it "JSQuery"? |
| Previous Message | Noah Misch | 2014-06-05 23:36:23 | Re: Allowing join removals for more join types |