Re: Performance problems with prepared statements
От | Merlin Moncure |
---|---|
Тема | Re: Performance problems with prepared statements |
Дата | |
Msg-id | b42b73150710111028h51a6798agf862e5e88cbc123c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance problems with prepared statements (Theo Kramer <theo@flame.co.za>) |
Ответы |
Re: Performance problems with prepared statements
|
Список | pgsql-performance |
On 10/11/07, Theo Kramer <theo@flame.co.za> wrote: > On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote: > > Theo Kramer wrote: > > > > > > So I suspect that there is something more fundamental here... > > > > OK, so there must be something different between the two scenarios. It > > can only be one of: > > 1. Query > > 2. DB Environment (user, locale, settings) > > 3. Network environment (server/client/network activity etc) > > I suspect that it could also be in the way the libpq PQprepare(), and > PQexecPrepared() are handled... as opposed to the way PREPARE and > EXECUTE are handled. PQexecPrepared is generally the fastest way to run queries from a C app as long as you get the right plan. Some suggestions * you can explain/explain analyze executing prepared statements from psql shell...try that and see if you can reproduce results * at worst case you can drop to execParams which is faster (and better) than PQexec, at least * if problem is plan related, you can always disable certain plan types (seqscan), prepare, and re-enable those plan types * do as Jonah suggested, first step is to try and reproduce problem from psql merlin
В списке pgsql-performance по дате отправления: