From: | Bosco Rama <postgres(at)boscorama(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: select vs cursor/fetch speed disparity |
Date: | 2011-10-10 16:13:03 |
Message-ID: | 4E93198F.5090001@boscorama.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Tom,
Tom Lane wrote:
> Bosco Rama <postgres(at)boscorama(dot)com> writes:
>> I have a strange disparity between a query that is run as a
>> straight select and the same query via a cursor. I hope I can
>> jog someone's memory with the description as I have been unable
>> to create a sanitized and/or reduced data set & schema that will
>> reproduce this ... so far. :-(
>
> Cursors are biased towards fast-start plans on the theory that you
> may not be intending to fetch the whole result. Queries with ORDER BY
> and/or LIMIT are particularly likely to see plan changes as a
> consequence of that. In 8.4 and up you can frob the
> cursor_tuple_fraction setting to adjust this preference. Use
> "EXPLAIN query" vs "EXPLAIN DECLARE CURSOR FOR query" to see what
> sort of plan you're getting.
I'll take a look at that setting and try the two 'explain's. However,
would that really account for an increase in time by a factor of ~630?
Just wondering.
(BTW, I'm still working on a public version of the data & schema that
reproduce this.)
Bosco.
From | Date | Subject | |
---|---|---|---|
Next Message | Brandon Phelps | 2011-10-10 16:30:12 | Hot standby won't start |
Previous Message | Steve Crawford | 2011-10-10 16:06:28 | Re: PostgreSQL consulting companies in the Bay Area |