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