From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Subject: | Re: 7.3 schedule |
Date: | 2002-04-14 19:21:44 |
Message-ID: | 20020414212144.A12196@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 12, 2002 at 12:51:26PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Certainly a shared cache would be good for apps that connect to issue a
> > single query frequently. In such cases, there would be no local cache
> > to use.
>
> We have enough other problems with the single-query-per-connection
> scenario that I see no reason to believe that a shared plan cache will
> help materially. The correct answer for those folks will *always* be
> to find a way to reuse the connection.
My query cache was write for 7.0. If some next release will use
pre-forked backend and after a client disconnection the backend will
still alives and waits for new client the shared cache is (maybe:-) not
needful. The current backend fork model is killer of all possible
caching.
We have more caches. I hope persistent backend help will help to all
and I'm sure that speed will grow up with persistent backend and
persistent caches without shared memory usage. There I can agree with
Tom :-)
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Loftis | 2002-04-14 19:59:09 | Re: Redhat 7.2.93 performance (was:Re: PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC) |
Previous Message | Lamar Owen | 2002-04-14 19:15:39 | Re: Redhat 7.2.93 performance (was:Re: PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC) |