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).
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-02-09 22:23:09|
|Subject: Re: Some belated patch review for "Buffers" explain analyze patch|
|Previous:||From: Tom Lane||Date: 2010-02-09 22:07:25|
|Subject: Re: Some belated patch review for "Buffers" explain analyze patch |