Skip site navigation (1) Skip section navigation (2)

Re: Avoiding bad prepared-statement plans.

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: "Pierre C" <lists(at)peufeu(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-02-19 17:56:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Pierre C" <lists(at)peufeu(dot)com> writes:
> Yep, but it's a bit awkward and time-consuming, and not quite suited to
> ORM-generated requests since you got to generate all the plan names, when
> the SQL query itself would be the most convenient "unique
> identifier"...

The SHA1 proposal seems better to me.

Now you still have to fill the table with statements and names, and I
stand on the opinion that having a development-only layer in the ORM to
do just that is better.

That's supposing you don't generate so many different normalized queries
that you can't generate them all in dev or from the unit tests…

> A cool hack would be something like that :
> pg_execute( "SELECT ...", arguments... )
> By inserting a hook which calls a user-specified function on non-existing
> plan instead of raising an error, this could work.

This I'm not helping with. It's definitely not the same skills and time
requirements as offering a simple function based alternative to the
table lookup in preprepare, in the "load them all" phase.

> However, this wouldn't work as-is since the plan name must be <=
> NAMEDATALEN, but you get the idea ;)

SHA1 or even MD5 would do, the later having the advantage of being
already supported by PostgreSQL core.


In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-02-19 18:22:22
Subject: Re: ALTER ROLE/DATABASE RESET ALL versus security
Previous:From: Tom LaneDate: 2010-02-19 17:15:58
Subject: Re: Merge join and index scan strangeness

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group