Re: Cursors and different settings for default_statistics_target

From: "Hell, Robert" <Robert(dot)Hell(at)fabasoft(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Cursors and different settings for default_statistics_target
Date: 2008-04-02 10:11:06
Message-ID: B710F3299F04664DB6B37C258FDEEB940158B255@FABAMAIL.fabagl.fabasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I'm motivated to contribute a patch for that.

I would prefer to make tuple_fraction for cursors configurable as GUC
parameter cursor_tuple_fraction.
Do you agree with that?

Regards,
Robert

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Mittwoch, 02. April 2008 00:24
To: Hell, Robert
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Cursors and different settings for
default_statistics_target

"Hell, Robert" <Robert(dot)Hell(at)fabasoft(dot)com> 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
order and return whichever of them happen to match the IN list. So I
think you're just saying that your IN list isn't uniformly dense through
the whole set of objids.

If the real story is that you tend to select only objids within a narrow
range, adding explicit "AND objid >= x AND objid <= y" constraints
(where you compute x and y on the fly from the set of objids you're
asking for) would reduce the overhead of the indexscan.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message James Mansion 2008-04-02 19:10:29 Re: POSIX file updates
Previous Message Arjen van der Meijden 2008-04-02 06:44:39 Re: SSDs