| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mayrom Rabinovich <mayromrabinovich(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Planing edge case for sorts with limit on non null column |
| Date: | 2026-02-05 15:46:37 |
| Message-ID: | 1615618.1770306397@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mayrom Rabinovich <mayromrabinovich(at)gmail(dot)com> writes:
> -- same deal query by the reverse order of the index, but also specify the
> wrong null order
> -- from my understanding this should not matter because we don't have any
> nulls on the table
> -- due to the constraint.
No, that is not taken into account. The planner's notion of a
concrete sort order always includes a nulls first/last flag, and this
index doesn't match what the query asks for. If you want this query
to use an index you'll need to make an index that puts nulls at the
other end (either ASC NULLS FIRST or DESC NULLS LAST will do).
I'm not really excited about poking holes in the PathKey concept to
make this work the way you want. I think the odds of introducing bugs
would be high. Also, the question could be turned around: if you know
that the table contains no nulls, why are you going out of your way to
specify the "wrong" null order?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-02-05 16:19:46 | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |
| Previous Message | Nathan Bossart | 2026-02-05 15:44:50 | Re: [PATCH] Support reading large objects with pg_read_all_data |