| From: | Andrei Zhidenkov <andrei(dot)zhidenkov(at)n26(dot)com> |
|---|---|
| To: | Игорь Выскорко <vyskorko(dot)igor(at)yandex(dot)ru> |
| Cc: | Igor Neyman <ineyman(at)perceptron(dot)com>, zzzzz(dot)graf(at)gmail(dot)com, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Weird seqscan node plan |
| Date: | 2019-11-27 08:42:10 |
| Message-ID: | AB4858A2-025C-4995-B275-66B1E66AEEDE@n26.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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(dot)igor(at)yandex(dot)ru> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lauri Kajan | 2019-11-27 09:32:10 | Range contains element filter not using index of the element column |
| Previous Message | Игорь Выскорко | 2019-11-27 03:53:42 | Re: Weird seqscan node plan |