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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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