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

Re: Any better plan for this query?..

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Dimitri <dimitrik(dot)fr(at)gmail(dot)com>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Any better plan for this query?..
Date: 2009-05-11 22:54:29
Message-ID: 20090511225429.GM8689@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-performance
Dimitri escribió:
> Hi Aidan,
> 
> thanks a lot for this detailed summary!
> 
> So, why I don't use prepare here: let's say I'm testing the worst
> stress case :-)  Imagine you have thousands of such kind of queries -
> you cannot prepare all of them! :-)

Thousands?  Surely there'll be a dozen or three of most common queries,
to which you pass different parameters.  You can prepare thoseu

> Now, as you see from your explanation, the Part #2 is the most
> dominant - so why instead to blame this query not to implement a QUERY
> PLANNER CACHE??? - in way if any *similar* query is recognized by
> parser we simply *reuse* the same plan?..

This has been discussed in the past, but it turns out that a real
implementation is a lot harder than it seems.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2009-05-11 23:02:19
Subject: Re: Query planner making bad decisions
Previous:From: DimitriDate: 2009-05-11 22:46:53
Subject: Re: Any better plan for this query?..

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