Skip site navigation (1) Skip section navigation (2)

Re: JDBC, prepared queries, and partitioning

From: "Stephen Denne" <Stephen(dot)Denne(at)datamail(dot)co(dot)nz>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Kris Jurka" <books(at)ejurka(dot)com>,"Josh Berkus" <josh(at)agliodbs(dot)com>,"PostgreSQL - JDBC" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC, prepared queries, and partitioning
Date: 2008-02-13 21:45:52
Message-ID: F0238EBA67824444BC1CB4700960CB4804A4F683@dmpeints002.isotach.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Simon Riggs wrote
> ISTM we need a way to say "this query's parameters vary wildly at
> execution time, so I really need to re-plan it every time".

If the wild variations don't affect the cost estimate, they won't affect the plan?

Isn't it more a case of
"even a minor variation in just one of this query's parameters can result in wildly different cost estimate, 
so I really need to re-plan it every time."

This is something that the database may be able to determine from currently collected statistics.

However I suspect that any means of trying to automatically determine that would *always* result in 
"Yep, minor changes can wildly affect the cost estimate"

(I'm ignorant of details and history but...)

Could this be added (conditionally):
With the stored plan, store the cost estimate,
Re-estimate the cost of the chosen plan with the newly supplied parameters,
If the new cost is significantly higher then re-plan.

Checking the cost of a plan every time should be a lot cheaper than always re-planning.

I can already see problems with this...
the query will get slower and slower over time as it settles onto the plan that best handles the worst cases.

Stephen Denne.

Disclaimer:
At the Datamail Group we value team commitment, respect, achievement, customer focus, and courage. This email with any attachments is confidential and may be subject to legal privilege.  If it is not intended for you please advise by reply immediately, destroy it and do not copy, disclose or use it in any way.

__________________________________________________________________
  This email has been scanned by the DMZGlobal Business Quality 
              Electronic Messaging Suite.
Please see http://www.dmzglobal.com/services/bqem.htm for details.
__________________________________________________________________



In response to

Responses

pgsql-jdbc by date

Next:From: Tom LaneDate: 2008-02-13 21:50:38
Subject: Re: JDBC, prepared queries, and partitioning
Previous:From: Kris JurkaDate: 2008-02-13 21:41:26
Subject: Re: JDBC, prepared queries, and partitioning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group