From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
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 22:43:49 |
Message-ID: | 29952.1047509029@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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 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".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2003-03-12 22:44:12 | Re: Help with determining a database's size |
Previous Message | Carla Moema Hartstein | 2003-03-12 22:41:07 | Cancel |