Re: Inheritance efficiency - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Inheritance efficiency
Date
Msg-id 9870F727-ECE9-43F6-8496-666BBAB82343@solfertje.student.utwente.nl
Whole thread Raw
In response to Re: Inheritance efficiency  (Alban Hertroys <dalroi@solfertje.student.utwente.nl>)
List pgsql-general
On 1 May 2010, at 12:56, Alban Hertroys wrote:

> You could argue that some logic could be added to the handling of prepared statements to insert query-subplans
dependingon what data you use for your parameters, but then you're moving back in the direction of unprepared
statements(namely invoking the query planner). It would help cases like this one, but it would hurt all other prepared
statements.It would at the least add a parse tree back into the queries path, which would be a fairly simplistic one in
thecase of table partitioning, but would get fairly complex for prepared statements involving more parameters - so much
sothat the benefit of using a prepared statement (not spending time planning the query) would get reduced
significantly.


And of course it would add time for planning the query-tree to the creation of the prepared statement - which could be
significantcompared to the time people expect to save by not invoking the planner on later invocations of the same
query.That said, the more frequent the query is executed the less that hurts performance, while it doesn't really
matterfor queries that are executed infrequently. 

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,4bdc0ba010411331128920!



pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Inheritance efficiency
Next
From: Tom Lane
Date:
Subject: Re: Native DB replication for PG