From: Tom Lane <tgl@sss.pgh.pa.us>
To: André Hänsel <andre@webkr.de>
Cc: 'Pgsql Performance' <pgsql-performance@lists.postgresql.org>
Subject: Re: Why is there a Sort after an Index Only Scan?
Date: Wed, 04 May 2022 22:08:59 -0400
Message-ID: <2604686.1651716539@sss.pgh.pa.us> (raw)
In-Reply-To: <015101d8601d$37df5190$a79df4b0$@webkr.de>
References: <014601d8600c$e15aadc0$a4100940$@webkr.de>
<CAApHDvr-apH5h5NpsS=jDPhiGugoBrLz3SbU37xR+1Dg3u7OMQ@mail.gmail.com>
<015101d8601d$37df5190$a79df4b0$@webkr.de>
=?UTF-8?Q?Andr=C3=A9_H=C3=A4nsel?= <andre@webkr.de> writes:
> Limit (cost=0.43..296.63 rows=50 width=4) (actual time=1052.692..1052.737 rows=50 loops=1)
> -> Index Scan using orders_test_pkey on orders_test (cost=0.43..71149.43 rows=12010 width=4) (actual time=1052.690..1052.728 rows=50 loops=1)
> Filter: ((shipping_date >= '2022-04-30'::date) AND (shipping_date <= '2022-05-01'::date))
> Rows Removed by Filter: 1998734
> Is it overestimating the cost of the sorting?
No, but it's guessing it will hit 50 rows that satisfy the filter
before it's gone very far in this index. If the shipping date and
pkey are correlated in the wrong direction, that could be a very
overoptimistic guess. I don't think we have adequate stats yet
to detect this sort of problem.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, andre@webkr.de, pgsql-performance@lists.postgresql.org
Subject: Re: Why is there a Sort after an Index Only Scan?
In-Reply-To: <2604686.1651716539@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox