Re: Startup cost of sequential scan

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