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

Re: Avoiding bad prepared-statement plans.

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>
Cc: Yeb Havinga <yebhavinga(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-02-09 22:21:43
Message-ID: m2zl3inj7s.fsf@hi-media.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Jeroen Vermeulen <jtv(at)xs4all(dot)nl> writes:
> I think we should be careful not to over-think this.  Planning isn't *that*
> costly, so apply Amdahl's Law liberally.  I'm proposing some easy things we
> could do without adding much overhead or maintenance burden; I've been
> assuming that getting intimate with the planner would risk those advantages.

On a project where performance is a must (5ms per query is about all you
can ask) I have queries for which planning is 40+ ms and execute 2 to 5
ms (dataset fits in RAM, by design).

I'm then abusing pgbouncer so that the PREPARE is shared by a lot of
clients, all the ones landing into the session (transaction pooling).

See preprepare to get a better idea, even if we're yet to run it (it's
being used in production elsewhere, though, I've been told).

  http://preprepare.projects.postgresql.org/

Regards,
-- 
dim

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-09 22:23:09
Subject: Re: Some belated patch review for "Buffers" explain analyze patch
Previous:From: Tom LaneDate: 2010-02-09 22:07:25
Subject: Re: Some belated patch review for "Buffers" explain analyze patch

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