Re: Using functions as filters in queries

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chris Mungall <cjm(at)fruitfly(dot)org>, <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Using functions as filters in queries
Date: 2003-03-12 23:09:17
Message-ID: 20030312150753.H58222-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Wed, 12 Mar 2003, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > Of course, I misread what explain did (without trying the
> > enable_seqscan=off case) and this is still not indexable because even
> > after that, you'll not get a clause on the outside that it considers
> > indexable. It is smart enough (7.4 anyway) to make the filter ((t.*).n)=5
> > which I thought it'd index, but doesn't. :(
>
> Note that inline-expansion of SQL functions like this is new for 7.4;
> it's not done in any current release.

I wasn't sure when it was added.

> I think the extra step to make this expression indexable is probably not
> too hard: the constant-expression folder needs to be taught that
> extracting a field from a whole-row Var can be replaced by a Var
> reference to the field, ie, fold "(t.*).n" into "t.n".

That's what I figured, but I wasn't sure if there was some case where it
was unsafe.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2003-03-12 23:40:14 Re: Using functions as filters in queries
Previous Message Robert Treat 2003-03-12 22:51:08 Re: Upgrade 7.2.1 to 7.3