From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Subject: | Re: Comments for lossy ORDER BY are lacking |
Date: | 2019-04-19 00:37:00 |
Message-ID: | 20190419003700.7geq3yc6mtrft7n4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-04-18 17:30:20 -0700, Andres Freund wrote:
> For not the first time I was trying to remember why and when the whole
> nodeIndexscan.c:IndexNextWithReorder() business is needed. The comment
> about reordering
>
> * IndexNextWithReorder
> *
> * Like IndexNext, but this version can also re-check ORDER BY
> * expressions, and reorder the tuples as necessary.
>
> or
> + /* Initialize sort support, if we need to re-check ORDER BY exprs */
>
> or
>
> + /*
> + * If there are ORDER BY expressions, look up the sort operators for
> + * their datatypes.
> + */
Secondary point: has anybody actually checked whether the extra
reordering infrastructure is a measurable overhead? It's obviously fine
for index scans that need reordering (i.e. lossy ones), but currently
it's at least initialized for distance based order bys. I guess that's
largely because currently opclasses don't signal the fact that they
might return loss amcanorderby results, but that seems like it could
have been fixed back then?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-04-19 00:38:06 | Re: finding changed blocks using WAL scanning |
Previous Message | Peter Geoghegan | 2019-04-19 00:33:55 | Re: Pathological performance when inserting many NULLs into a unique index |