From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Brown <dave(at)spoonguard(dot)org> |
Cc: | PostgreSQL Global Development Group <pgsql-patches(at)postgresql(dot)org>, Charlie Peck <charliep(at)cs(dot)earlham(dot)edu> |
Subject: | Re: Allow pooled connections to list all prepared queries |
Date: | 2004-12-24 16:00:57 |
Message-ID: | 8655.1103904057@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
David Brown <dave(at)spoonguard(dot)org> writes:
> Attached is a loadable module (and a small backend patch) that allows a
> client to list the available query plans (created with PREPARE, or with a
> 'parse' protocol message) on a particular connection.
> * Extended PostgreSQL's SQL grammar to capture the original SQL query
> string for PREPARE statements.
This seems much the ugliest and most invasive part of the patch. I'd
suggest doing something similar to what pg_proc.c is doing:
/* We can get the original query text from the active portal (hack...) */
Assert(ActivePortal && ActivePortal->status == PORTAL_ACTIVE);
queryText = ActivePortal->sourceText;
> * Modified backend/commands/prepare.c to keep some additional statistics
> in the prepared statement hash table (plan creation time, execution
> count, etc.)
The usefulness of this seems pretty dubious. You aren't going to have a
bunch of random bits of code sharing a connection; it's going to be a
single application that probably knows perfectly well exactly which
queries it needs prepared. So I don't think the stats will pay for
themselves.
> * Added an accessor function to allow for "raw" access to the prepared
> statement hash table (necessary for sequential access).
It would have been better to put the function that needs this access
into prepare.c. There is no point in trying to hide a data structure
inside a module if we then turn around and expose the data structure
to the world...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-24 16:16:35 | Re: RC2 and open issues |
Previous Message | Bruce Momjian | 2004-12-24 15:46:27 | Re: RC2 and open issues |