Search Postgresql Archives

Re: Weird seqscan node plan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At this point I disagree. It’s faster to fetch one row using seq scan that using index scan as well as fetching number of consecutive rows is faster via seq scan. Index scan is not always faster.

On 27. Nov 2019, at 04:53, Игорь Выскорко <vyskorko.igor@xxxxxxxxx> wrote:

Why planner mistakes in determining the number of rows (every time planner expects only 1 row) in this step I can understand - inner nodes do some joins (inner and outer with filtration) and it's hard to predict result.
But what I can't understand is why seq scan when it is always slower than index.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux