00:24
To: Hell, Robert
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Cursors and different settings for
default_statistics_target
"Hell, Robert" <[EMAIL PROTECTED]> writes:
> But why are the first 15 fetches (15360 rows) processed in 0.5 seconds
and the last
"Hell, Robert" <[EMAIL PROTECTED]> writes:
> But why are the first 15 fetches (15360 rows) processed in 0.5 seconds and
> the last fetch (998 rows) takes 7 seconds.
> Are we just unlucky that the last fetch takes that long?
Well, the indexscan plan is going to scan through all the rows in objid
o
d = ANY ('{281479288456304,,285774255837674}'::bigint[]))
Regards,
Robert
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 01. April 2008 18:42
An: Hell, Robert
Cc: pgsql-performance@postgresql.org
Betreff: Re: [PERFORM] Cursors and different set
On Tue, Apr 01, 2008 at 12:42:03PM -0400, Tom Lane wrote:
>> That's CURSOR_OPT_FAST_PLAN and isn't it? Our application reads the full
>> results of most cursors.
> Just out of curiosity, why use a cursor at all then?
This isn't the same scenario as the OP, but I've used a cursor in cases where
I c
"Hell, Robert" <[EMAIL PROTECTED]> writes:
> That's CURSOR_OPT_FAST_PLAN and isn't it? Our application reads the full
> results of most cursors.
Just out of curiosity, why use a cursor at all then? But anyway, you
might want to consider running a custom build with a higher setting for
tuple_fract
ert
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 01. April 2008 18:17
To: Hell, Robert
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Cursors and different settings for
default_statistics_target
"Hell, Robert" <[EMAIL PROTECTED]> write
"Hell, Robert" <[EMAIL PROTECTED]> 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 differ
x27;s the difference between plan calculation for cursors and straight
queries?
Kind regards,
Robert
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 01. April 2008 17:30
To: Hell, Robert
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Cursor
"Hell, Robert" <[EMAIL PROTECTED]> writes:
> When we use 20 as default_statistics_target the retrieval of the data
> takes 7.5 seconds - with 25 as default_statistics_target (with restart
> and analyze) it takes 0.6 seconds.
> The query plan is identical in both situations (row estimation differs a
Hi,
the following statement retrieves 16358 rows in a cursor by fetching
1024 rows in bulks on a 8.2.4 server:
DECLARE curs_285058224 CURSOR FOR SELECT objid, attrid, aggrid, lineid,
objval FROM atobjval WHERE objid IN
(281479288456304,281479288456359,281479288456360,281479288456384,2814792
88456
10 matches
Mail list logo
