From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transient plans versus the SPI API |
Date: | 2011-08-04 09:12:24 |
Message-ID: | 4E3A6278.3050404@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2011-08-03 21:19, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>> This seems like a good design. Now what would be really cool is if
>> you could observe a stream of queries like this:
>> SELECT a, b FROM foo WHERE c = 123
>> SELECT a, b FROM foo WHERE c = 97
>> SELECT a, b FROM foo WHERE c = 236
>> ...and say, hey, I could just make a generic plan and use it every
>> time I see one of these. It's not too clear to me how you'd make
>> recognition of such queries cheap enough to be practical, but maybe
>> someone will think of a way...
> Hm, you mean reverse-engineering the parameterization of the query?
> Interesting thought, but I really don't see a way to make it practical.
See also http://archives.postgresql.org/pgsql-hackers/2010-11/msg00617.php
I don't know if any implementation can be practical - maybe the parser
could be coerced into emitting some kind of number that's based on
everything in the query, except constants (and whitespace), so it would
be the same for all the queries Robert described. That could be low cost
enough to detect of for a query's id a cached plan exists and do more
work only in those cases.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-08-04 09:12:55 | Re: Postgres / plpgsql equivalent to python's getattr() ? |
Previous Message | Boszormenyi Zoltan | 2011-08-04 09:10:01 | Re: SYNONYMS (again) |