| From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> | 
|---|---|
| To: | theo(at)flame(dot)co(dot)za | 
| Cc: | pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: Performance problems with prepared statements | 
| Date: | 2007-10-11 17:28:51 | 
| Message-ID: | b42b73150710111028h51a6798agf862e5e88cbc123c@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
On 10/11/07, Theo Kramer <theo(at)flame(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-10-11 17:49:43 | Re: Huge amount of memory consumed during transaction | 
| Previous Message | Erik Jones | 2007-10-11 16:51:08 | Re: Huge amount of memory consumed during transaction |