From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Jim Nasby <jim(at)nasby(dot)net> |
Subject: | Re: Patch to support SEMI and ANTI join removal |
Date: | 2014-10-06 15:05:03 |
Message-ID: | CA+TgmoasyBUWHeKqzhK3ZzV2RHN2LCh==uS+Xp5O0noxopHe5Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 6, 2014 at 10:59 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-10-06 10:46:09 -0400, Robert Haas wrote:
>> This seems messy, though. Can't the deferred trigger queue become
>> non-empty at pretty much any point in time? At exactly what point are
>> we making this decision, and how do we know the correct answer can't
>> change after that point?
>
> What we've been talking about is doing this during executor startup. And
> at that point we really don't care about new entries in the queue during
> query execution - we can't see them anyway.
Ah, OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ali Akbar | 2014-10-06 15:12:55 | Re: Add generate_series(numeric, numeric) |
Previous Message | Robert Haas | 2014-10-06 15:04:18 | Re: CRC algorithm (was Re: [REVIEW] Re: Compression of full-page-writes) |