Re: Startup cost of sequential scan - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Startup cost of sequential scan
Date
Msg-id CAPpHfduiJw-sswW7ked_ONAcugo-kJ8aKfEeM1fdofkpoWEQyA@mail.gmail.com
Whole thread Raw
In response to Re: Startup cost of sequential scan  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
On Thu, Aug 30, 2018 at 6:08 PM Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
> On 30.08.2018 17:58, Tom Lane wrote:
> > Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> >> On Thu, Aug 30, 2018 at 5:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Because it's what the mental model of startup cost says it should be.
> >>  From this model we make a conclusion that we're starting getting rows
> >> from sequential scan sooner than from index scan.  And this conclusion
> >> doesn't reflect reality.
> > No, startup cost is not the "time to find the first row".  It's overhead
> > paid before you even get to start examining rows.
> But it seems to me that calculation of cost in LIMIT node contradicts
> with this statement:
>
>              pathnode->path.startup_cost +=
>                  (subpath->total_cost - subpath->startup_cost)
>                  * offset_rows / subpath->rows;

Why does it contradict?  It just assumes that skipping OFFSET rows to
be preliminary work before returning results rows...

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Startup cost of sequential scan
Next
From: Andrew Gierth
Date:
Subject: Re: Startup cost of sequential scan