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

Re: How to interpret this explain analyse?

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: "Pgsql-Performance (E-mail)" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: How to interpret this explain analyse?
Date: 2005-02-16 21:09:28
Message-ID: 20050216210928.GB31014@filer (view raw or flat)
Thread:
Lists: pgsql-performance
Greg Stark wrote:
> 
> Kevin Brown <kevin(at)sysexperts(dot)com> writes:
> > Also, one has to ask what the consequences are of assuming a value too
> > low versus too high.  Which ends up being worse?
> 
> This is one of the things the planner really cannot know. Ultimately it's the
> kind of thing for which hints really are necessary. Oracle distinguishes
> between the "minimize total time" versus "minimize startup time" with
> /*+ ALL_ROWS */ and /*+ FIRST_ROWS */ hints, for example.

Well, the planner *can* know the actual value to use in this case, or
at least a close approximation, but the system would have to gather
some information about cursors during fetches.  At the very least, it
will know how many rows were actually fetched by the cursor in
question, and it will also hopefully know how many rows were returned
by the query being executed.  Store the ratio of the two in a list,
then store the list itself into a table (or something) at backend exit
time.


-- 
Kevin Brown					      kevin(at)sysexperts(dot)com

In response to

pgsql-performance by date

Next:From: Ron MayerDate: 2005-02-17 03:22:19
Subject: Re: seq scan cache vs. index cache smackdown
Previous:From: Greg StarkDate: 2005-02-16 04:19:25
Subject: Re: seq scan cache vs. index cache smackdown

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