Skip site navigation (1) Skip section navigation (2)

Re: How to interpret this explain analyse?

From: "Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)nl>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Richard Huxton" <dev(at)archonet(dot)com>,"Pgsql-Performance (E-mail)" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: How to interpret this explain analyse?
Date: 2005-02-11 23:12:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Hi Tom,

Tom Lane schreef:
> Well, the planner does put some emphasis on startup time when dealing
> with a DECLARE CURSOR plan; the problem you face is just that that
> correction isn't large enough.  (From memory, I think it optimizes on
> the assumption that 10% of the estimated rows will actually
> be fetched; you evidently want a setting of 1% or even less.)
I wish I had your mnemory ;-) . The tables contain 1.100.000 records by the way  (that is not nearly 10 %, my math is not that good))

> We once talked about setting up a GUC variable to control the
> percentage of a cursor that is estimated to be fetched:
> It never got done but that seems like the most reasonable solution to
> me. 
If the proposal means that the cursor is not limited to ths limit in the query but is limited to the fetch than I support the proposal. A bit late I presume.


Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J(dot)Kraaijeveld(at)Askesis(dot)nl

pgsql-performance by date

Next:From: Christopher BrowneDate: 2005-02-13 01:34:24
Subject: Re: Benchmark
Previous:From: Merlin MoncureDate: 2005-02-11 20:41:58
Subject: Re: Benchmark

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group