Failure to use generic plans (was: Re: Performance problem in PLPgSQL)

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Failure to use generic plans (was: Re: Performance problem in PLPgSQL)
Date: 2013-07-23 23:47:24
Message-ID: 0e6d70debaf899bfbf37edcdfbd03e21@news-out.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

As failures to use a generic plan goes, that one's fairly tame. I've
seen much worse. For example:

PREPARE foo(integer[]) AS SELECT * FROM complexview WHERE id = ANY ($1);

where the caller typically supplies 1-5 array elements (or any number
less than 10, because generic parameter arrays are assumed to have 10
elements). This one can be a massive performance regression between
9.1 and 9.2; the first guy who mentioned this on IRC was getting a 40x
slowdown (~20ms planning time vs. 0.5ms execution time).

--
Andrew (irc:RhodiumToad)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-07-24 00:35:27 Re: Review: UNNEST (and other functions) WITH ORDINALITY
Previous Message Tom Lane 2013-07-23 22:53:25 Re: Performance problem in PLPgSQL