Re: Query caching

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: devik(at)cdi(dot)cz
Cc: Christof Petig <christof(dot)petig(at)wtal(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Meskes <meskes(at)postgresql(dot)org>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, The Hermit Hacker <scrappy(at)hub(dot)org>
Subject: Re: Query caching
Date: 2000-11-12 11:34:51
Message-ID: Pine.LNX.3.96.1001112121835.30482B-100000@ara.zf.jcu.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 10 Nov 2000 devik(at)cdi(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2000-11-12 16:16:18 SYSLOG/LOG_LOCAL0
Previous Message The Hermit Hacker 2000-11-12 08:36:32 [RELEASE ANNOUNCEMENT] v7.0.3 *Final* now Available