From: | Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk> |
---|---|
To: | Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query using cursors using 100% CPU |
Date: | 2008-02-12 17:09:54 |
Message-ID: | 200802121709.55134.mark.cave-ayland@siriusit.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday 12 February 2008 16:03:31 Glyn Astill wrote:
> Thanks Mark,
>
> I've turned this on and I never see a DECLARE CURSOR so I presume I
> was wrong and it is not using cursors.
>
> I do see a DEALLOCATE though, although no PREPARE. Before this it
> does lots of statements that are limited to 100 records, and all the
> statements are named and preceded by execute, so I presume it is
> using prepared statements getting little chunks of data and relying
> on the first execute to prepare them?
Yup, it's using prepared queries. Unfortunately prepared queries are not
always a good thing, because if your data is non-uniformly distributed then
the planner has guess what will be the best plan without knowing what
parameters you are passing in at run-time. Hence you may get a plan that is
optimal for one set of values, but not for others.
> Both tests were run over the network.
Okay. From what you mention above, it's likely that what you're seeing is a
bad query plan choice anyway.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2008-02-12 17:31:05 | Re: deadlock while re-indexing table |
Previous Message | Ivan Sergio Borgonovo | 2008-02-12 16:52:10 | Re: end of life for pg versions... |