Re: Inheritance efficiency

From: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
To: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Inheritance efficiency
Date: 2010-05-01 11:08:08
Message-ID: 9870F727-ECE9-43F6-8496-666BBAB82343@solfertje.student.utwente.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 depending on 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 the case of table partitioning, but would get fairly complex for prepared statements involving more parameters - so much so that 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 significant compared 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 matter for 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!

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2010-05-01 15:27:46 Re: Native DB replication for PG
Previous Message Alban Hertroys 2010-05-01 10:56:38 Re: Inheritance efficiency