Re: [0/4] Proposal of SE-PostgreSQL patches

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

In response to

Browse pgsql-hackers by date

  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.

Browse pgsql-patches by date

  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