From: | Alfred Perlstein <bright(at)wintelcom(dot)net> |
---|---|
To: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Query cache import? |
Date: | 2000-11-01 00:40:33 |
Message-ID: | 20001031164033.J22110@fw.wintelcom.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> [001031 16:18] wrote:
>
> On Tue, 31 Oct 2000, Alfred Perlstein wrote:
>
> > I never saw much traffic regarding Karel's work on making stored
> > proceedures:
> >
> > http://people.freebsd.org/~alfred/karel-pgsql.txt
> >
> > What happened with this? It looked pretty interesting. :(
>
> It's probably a little about me :-) ... well,
>
> My query cache is in usable state and it's efficient for all
> things those motivate me to work on this.
>
> some basic features:
>
> - share parsed plans between backends in shared memory
> - store plans to private backend hash table
> - use parameters for stored queries
> - better design for SPI
> - memory usage for saved plans
> - save plans "by key"
>
>
> The current query cache code depend on 7.1 memory management. After
> official 7.1 release I prepare patch with query cache+SPI (if not
> hit me over head, please ..)
>
> All what will doing next time not depend on me, *it's on code developers*.
>
> For example Jan has interesting idea about caching all plans which
> processing backend. But it's far future and IMHO we must go by small
> steps to Oracle's funeral :-)
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. :)
--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."
From | Date | Subject | |
---|---|---|---|
Next Message | KuroiNeko | 2000-11-01 00:51:05 | Re: how good is PostgreSQL |
Previous Message | Steve Wolfe | 2000-11-01 00:39:54 | Re: how good is PostgreSQL |