From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hell, Robert <Robert.Hell@fabasoft.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Cursors and different settings for default_statistics_target
Date: Tue, 01 Apr 2008 12:16:59 -0400
Message-ID: <9629.1207066619@sss.pgh.pa.us> (raw)
In-Reply-To: <B710F3299F04664DB6B37C258FDEEB940158B0E9@FABAMAIL.fabagl.fabasoft.com>
References: <B710F3299F04664DB6B37C258FDEEB940158AFF9@FABAMAIL.fabagl.fabasoft.com>
<2798.1207063805@sss.pgh.pa.us>
<B710F3299F04664DB6B37C258FDEEB940158B0E9@FABAMAIL.fabagl.fabasoft.com>
"Hell, Robert" <Robert.Hell@fabasoft.com> writes:
> That's it - I found a more simple statement which has the same problem
> (0.02 seconds vs. 6 seconds):
This isn't necessarily the very same problem --- what are the plans for
your original case with the two different stats settings?
> What's the difference between plan calculation for cursors and straight
> queries?
The planner is set up to favor fast-start plans a little bit when
planning a cursor, on the theory that you are probably more interested
in getting some of the rows sooner than you are in the total runtime,
and that you might not ever intend to fetch all the rows anyway.
In the example you give here, it likes the indexscan/unique plan because
of the zero startup cost, even though the total cost is (correctly)
estimated as much higher. (Looking at this example, I wonder if the
fast-start bias isn't a bit too strong...)
It's not immediately apparent to me though how that would affect
your original query.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, Robert.Hell@fabasoft.com
Subject: Re: Cursors and different settings for default_statistics_target
In-Reply-To: <9629.1207066619@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox