Re: select vs cursor/fetch speed disparity

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.

In response to

Responses

Browse pgsql-general by date

  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