Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id 20100219135751.GD25733@it.is.rice.edu
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (David Christensen <david@endpoint.com>)
List pgsql-hackers
On Thu, Feb 18, 2010 at 08:31:05PM -0600, David Christensen wrote:
>
> On Feb 18, 2010, at 2:19 PM, Pierre C wrote:
>
>>
>>> What about catching the error in the application and INSERT'ing into the
>>> current preprepare.relation table? The aim would be to do that in dev or
>>> in pre-prod environments, then copy the table content in production.
>>
>> 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"...
>>
>> 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.
>> However, this wouldn't work as-is since the plan name must be <= 
>> NAMEDATALEN, but you get the idea ;)
>
> How about the SHA1 hash of the query?  Hey, it works for git... :-)
>
> Regards,
>
> David
> --
> David Christensen
> End Point Corporation
> david@endpoint.com
>
>
Hi David,

Not to beat out own drum, but we already include a hashing function
that can be used for this purpose and is much faster than SHA-1. We
would want to use all 64-bits for this use instead of just the 32-bits
we currently use for the internal DB hashing. Here is an article
comparing the Jenkins' Hash (the one we use) and SHA-1:

http://home.comcast.net/~bretm/hash/

Regards,
Ken


pgsql-hackers by date:

Previous
From: Yeb Havinga
Date:
Subject: Re: Merge join and index scan strangeness
Next
From: Tom Lane
Date:
Subject: Re: Merge join and index scan strangeness