On Thu, Aug 30, 2018 at 6:08 PM Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: > On 30.08.2018 17:58, Tom Lane wrote: > > Alexander Korotkov <a.korot...@postgrespro.ru> writes: > >> On Thu, Aug 30, 2018 at 5:05 PM Tom Lane <t...@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
