From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
Subject: | Re: [0/4] Proposal of SE-PostgreSQL patches |
Date: | 2008-05-12 14:52:37 |
Message-ID: | 19774.1210603957@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> Hmm. Is that really a good idea, compared to hard-wiring the checks
>> into nodeSeqscan and friends?
> My eyebrows went up when I read this too. Presumably, if it's hardwired
> like you suggest then the planner can't take any account of the filter,
> though. Do we want it to?
Well, the planner could have hardwired knowledge about the existence of
the hardwired filters --- if anything, that'd probably be easier than
hacking it to have a similar level of knowledge about generic-looking
function calls. But in reality, since we don't know at plan time which
userid will execute the constructed plan, I'm not sure we could come up
with useful estimates anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-05-12 15:10:28 | Re: [COMMITTERS] pgsql: Convert wal_sync_method to guc enum. |
Previous Message | Magnus Hagander | 2008-05-12 14:51:35 | Re: pgsql: Convert wal_sync_method to guc enum. |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-05-12 20:07:35 | Re: Snapshot management, final |
Previous Message | Andrew Dunstan | 2008-05-12 14:45:55 | Re: [0/4] Proposal of SE-PostgreSQL patches |