Re: Query cache import? - Mailing list pgsql-hackers

From Karel Zak
Subject Re: Query cache import?
Date
Msg-id Pine.LNX.3.96.1001101103137.8318A-100000@ara.zf.jcu.cz
Whole thread Raw
In response to Re: Query cache import?  (Alfred Perlstein <bright@wintelcom.net>)
List pgsql-hackers
On Tue, 31 Oct 2000, Alfred Perlstein wrote:

> * Karel Zak <zakkr@zf.jcu.cz> [001031 16:18] wrote:
> > 
> > On Tue, 31 Oct 2000, Alfred Perlstein wrote:
> > 
> >  All what will doing next time not depend on me, *it's on code developers*.                            ^^^^^^^^
              right is "core"
 

> Well I'm just hoping that perl's $dbh->prepare() actually does a
> temporary stored proceedure so that I can shave cycles off of 
> my thousands upon thousands of repeated queries. :)
IMHO implement good cache for planns is not easy, if is wanted
use cached planns in more backend and store it in shared memory. I
wrote for this new memory context type. My idea is not save/share 
parsed planns only for PREPARE/EXECUTE statemment but for SPI 
(triggers - FK for example) too. It expect support inside backend
and not is possible write it in some application layout (at client).
But it's very good "investment", because query pasring in the PG is
very expensive (all in queries is dynamic). In my tests is execute
for stored planns very faster (90%) for queries that spending more time
in the parser/planner/rewriter.
                        Karel



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: WAL: postmaster won't start
Next
From: Karel Zak
Date:
Subject: Re: Re: [GENERAL] Query caching