On Mon, Jun 16, 2003 at 10:11:00AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > Well, it would only need to make the checks if the table had partial
> > indexes. Even then, it probably makes sense to only do the check if
> > other query planning steps decide it would be useful to use the partial
> > index.
>
> You have that backwards. Planning is bottom-up, so we have to determine
> the relevant indexes *first*. Accordingly, a partial index is a
> performance drag on every query that uses its table, as we check to
> see if the partial index qual is satisfied by the query's WHERE clause.
> That's why I don't want it to be any slower than it is ...
Well, could it assume the index was valid until we got to the point
where we had to decide what index to use? In other words, don't do the
test unless the index appears to be the most attractive one. Also, as I
mentioned, if query parsing performance is that important, you can
explicitly add whatever clause will show the planner that the index is
valid.
Also, I just read that there's no statement plan caching, which makes me
a bit confused by this todo:
Flush cached query plans when their underlying catalog data changes
Does that only apply to pl/pgsql? Are there plans to add a statement
cache?
--
Jim C. Nasby (aka Decibel!) jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"