Re: 7.3 schedule

From: Curt Sampson <cjs(at)cynic(dot)net>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 7.3 schedule
Date: 2002-04-15 05:45:02
Message-ID: Pine.NEB.4.43.0204151437250.439-100000@angelic.cynic.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 14 Apr 2002, Barry Lind wrote:

> But since the syntax for prepare is: PREPARE <name> AS <statement> you
> can't easily reuse sql prepared by other PreparedStatement objects since
> you don't know if the sql you are about to execute has or has not yet
> been prepared or what <name> was used in that prepare. Thus you will
> always need to do a new prepare. (This only is true if the driver is
> trying to automatically use PREPARE/EXECUTE, which was the senario I was
> talking about).

Well, there are some ugly tricks you could build into the driver
to allow it to effectively use a PREPAREd statement with multiple,
identical PreparedStatement objects (basically, via the driver
caching various things and identifying PreparedStatements created
with the same SQL), but it's messy enough and has some problems
hard enough to resolve that I can't actually see this being practical.

I was actually just wanting to point out that this is where automatic
caching on the server shines.

> >>If it only is used once, it will actually perform worse....
>
> I didn't say it would be much worse, but it won't be faster than not
> using PREPARE.

Well, if it's not faster, that's fine. If it's worse, that's not
so fine, because as you point out there's really no way for the
driver to know whether a PreparedStatement is being used just for
speed (multiple queries with one instance) or security (on query,
but with parameters).

> I am just pointing out that I don't think the driver
> can behind the scenes use this capability automatically.

Well, if there's little or no performance impact, I would say that
the driver should always use this capability with PreparedStatement
objects. If there is a performance impact, perhaps a property could
turn it on and off?

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-15 06:07:18 Re: bug with current sources? Re: cost of parse/plan/execute for one sample query
Previous Message Tom Lane 2002-04-15 05:27:54 Re: ANSI Compliant Inserts