mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-08 16:23:22 +02:00
174 lines
6.3 KiB
Plaintext
174 lines
6.3 KiB
Plaintext
From owner-pgsql-hackers@hub.org Wed Nov 18 14:40:49 1998
|
|
Received: from hub.org (majordom@hub.org [209.47.148.200])
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id OAA29743
|
|
for <maillist@candle.pha.pa.us>; Wed, 18 Nov 1998 14:40:36 -0500 (EST)
|
|
Received: from localhost (majordom@localhost)
|
|
by hub.org (8.9.1/8.9.1) with SMTP id OAA03716;
|
|
Wed, 18 Nov 1998 14:37:04 -0500 (EST)
|
|
(envelope-from owner-pgsql-hackers@hub.org)
|
|
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Wed, 18 Nov 1998 14:34:39 +0000 (EST)
|
|
Received: (from majordom@localhost)
|
|
by hub.org (8.9.1/8.9.1) id OAA03395
|
|
for pgsql-hackers-outgoing; Wed, 18 Nov 1998 14:34:37 -0500 (EST)
|
|
(envelope-from owner-pgsql-hackers@postgreSQL.org)
|
|
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de [53.2.131.8])
|
|
by hub.org (8.9.1/8.9.1) with SMTP id OAA03381
|
|
for <pgsql-hackers@hub.org>; Wed, 18 Nov 1998 14:34:31 -0500 (EST)
|
|
(envelope-from wieck@sapserv.debis.de)
|
|
Received: by orion.SAPserv.Hamburg.dsh.de
|
|
for pgsql-hackers@hub.org
|
|
id m0zgDnj-000EBTC; Wed, 18 Nov 98 21:02 MET
|
|
Message-Id: <m0zgDnj-000EBTC@orion.SAPserv.Hamburg.dsh.de>
|
|
From: jwieck@debis.com (Jan Wieck)
|
|
Subject: Re: [HACKERS] PREPARE
|
|
To: meskes@usa.net (Michael Meskes)
|
|
Date: Wed, 18 Nov 1998 21:02:06 +0100 (MET)
|
|
Cc: pgsql-hackers@hub.org
|
|
Reply-To: jwieck@debis.com (Jan Wieck)
|
|
In-Reply-To: <19981118084843.B869@usa.net> from "Michael Meskes" at Nov 18, 98 08:48:43 am
|
|
X-Mailer: ELM [version 2.4 PL25]
|
|
Content-Type: text
|
|
Sender: owner-pgsql-hackers@postgreSQL.org
|
|
Precedence: bulk
|
|
Status: RO
|
|
|
|
Michael Meskes wrote:
|
|
|
|
>
|
|
> On Wed, Nov 18, 1998 at 03:23:30AM +0000, Thomas G. Lockhart wrote:
|
|
> > > I didn't get this one completly. What input do you mean?
|
|
> >
|
|
> > Just the original string/query to be prepared...
|
|
>
|
|
> I see. But wouldn't it be more useful to preprocess the query and store the
|
|
> resulting nodes instead? We don't want to parse the statement everytime a
|
|
> variable binding comes in.
|
|
|
|
Right. A real improvement would only be to have the prepared
|
|
execution plan in the backend and just giving the parameter
|
|
values.
|
|
|
|
I can think of the following construct:
|
|
|
|
PREPARE optimizable-statement;
|
|
|
|
That one will run parser/rewrite/planner, create a new memory
|
|
context with a unique identifier and saves the querytree's
|
|
and plan's in it. Parameter values are identified by the
|
|
usual $n notation. The command returns the identifier.
|
|
|
|
EXECUTE QUERY identifier [value [, ...]];
|
|
|
|
then get's back the prepared plan and querytree by the id,
|
|
creates an executor context with the given values in the
|
|
parameter array and calls ExecutorRun() for them.
|
|
|
|
The PREPARE needs to analyze the resulting parsetrees to get
|
|
the datatypes (and maybe atttypmod's) of the parameters, so
|
|
EXECUTE QUERY can convert the values into Datum's using the
|
|
types input functions. And the EXECUTE has to be handled
|
|
special in tcop (it's something between a regular query and
|
|
an utility statement). But it's not too hard to implement.
|
|
|
|
Finally a
|
|
|
|
FORGET QUERY identifier;
|
|
|
|
(don't remember how the others named it) will remove the
|
|
prepared plan etc. simply by destroying the memory context
|
|
and dropping the identifier from the id->mcontext+prepareinfo
|
|
mapping.
|
|
|
|
This all restricts the usage of PREPARE to optimizable
|
|
statements. Is it required to be able to prepare utility
|
|
statements (like CREATE TABLE or so) too?
|
|
|
|
|
|
Jan
|
|
|
|
--
|
|
|
|
#======================================================================#
|
|
# It's easier to get forgiveness for being wrong than for being right. #
|
|
# Let's break this rule - forgive me. #
|
|
#======================================== jwieck@debis.com (Jan Wieck) #
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M67@postgresql.org Tue Oct 31 19:18:16 2000
|
|
Received: from mail.postgresql.org ([216.126.85.28])
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA08916
|
|
for <pgman@candle.pha.pa.us>; Tue, 31 Oct 2000 19:18:15 -0500 (EST)
|
|
Received: from mail.postgresql.org ([216.126.85.28])
|
|
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eA10IOl60635;
|
|
Tue, 31 Oct 2000 19:18:24 -0500 (EST)
|
|
(envelope-from pgsql-hackers-owner+M67@postgresql.org)
|
|
Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
|
|
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eA10H8l60400
|
|
for <pgsql-hackers@postgresql.org>; Tue, 31 Oct 2000 19:17:08 -0500 (EST)
|
|
(envelope-from zakkr@zf.jcu.cz)
|
|
Received: from localhost (zakkr@localhost)
|
|
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id BAA32036;
|
|
Wed, 1 Nov 2000 01:16:42 +0100
|
|
Date: Wed, 1 Nov 2000 01:16:42 +0100 (CET)
|
|
From: Karel Zak <zakkr@zf.jcu.cz>
|
|
To: Alfred Perlstein <bright@wintelcom.net>
|
|
cc: pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Query cache import?
|
|
In-Reply-To: <20001031151144.F22110@fw.wintelcom.net>
|
|
Message-ID: <Pine.LNX.3.96.1001101005110.31713B-100000@ara.zf.jcu.cz>
|
|
MIME-Version: 1.0
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
|
|
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 :-)
|
|
|
|
If I need the query cache in the my work (typical for some web+pgsql) or
|
|
will some public interest I will continue on this, if not I freeze it.
|
|
(Exists more interesting work like http://mape.jcu.cz ... sorry of
|
|
advertising :-)
|
|
|
|
Karel
|
|
|
|
|
|
|
|
|
|
|
|
|