Re: Startup cost of sequential scan

On Thu, Aug 30, 2018 at 6:08 PM Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
> On 30.08.2018 17:58, Tom Lane wrote:
> > Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> >> On Thu, Aug 30, 2018 at 5:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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