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






