Re: Partial index where clause not filtering through
От | Jim C. Nasby |
---|---|
Тема | Re: Partial index where clause not filtering through |
Дата | |
Msg-id | 20030616223209.GK40542@flake.decibel.org обсуждение исходный текст |
Ответ на | Re: Partial index where clause not filtering through (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Partial index where clause not filtering through
|
Список | pgsql-performance |
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?"
В списке pgsql-performance по дате отправления: