Re: Query caching
Karel Zak <zakkr@zf.jcu.cz>
From: Karel Zak <zakkr@zf.jcu.cz>
To: devik@cdi.cz
Cc: Christof Petig <christof.petig@wtal.de>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Michael Meskes <meskes@postgresql.org>, Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>, The Hermit Hacker <scrappy@hub.org>
Date: 2000-11-12T11:34:51Z
Lists: pgsql-hackers
On Fri, 10 Nov 2000 devik@cdi.cz wrote: > Did someone think about query costs ? Is you prepare > query like SELECT id FROM t1 WHERE type=$1 and > execute it with $1=1 and 2. For 1 there is one record > in t1 a all other have type=2. > Without caching, first query will use index, second > not. > Should cached plan use index or not ? > devik The postgresql already have planns caching. See SPI (saveplan), but it's usable for internal stuff (for example triggers..) only. The PREPARE/EXECUTE pull up it to be<->fe and make new memory type that allows save it in shared memory. But else it's *nothing* new. A validity of cached planns is user problem now. Not some internal method how check changes that out of date some query (or exist some idea?). It can be more changes like changes in DB schema. If resolve this anyone clever person it will great for VIEW, SPI too. Rebuid a query plan in the planner is not a problem, in the cache is stored original query tree, but you must known when... or must know it a DB user. Karel