| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A qsort template |
| Date: | 2022-01-19 02:57:45 |
| Message-ID: | CAH2-WzmFuVN5P-LqwunMGzjfQDvCfn11g8qfh4MbGW0pvo4Deg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 18, 2022 at 6:39 PM John Naylor
<john(dot)naylor(at)enterprisedb(dot)com> wrote:
> Editorializing the null position in queries is not very common in my
> experience. Not null is interesting since it'd be trivial to pass
> constant false to the same Apply[XYZ]SortComparator() and let the
> compiler remove all those branches for us. On the other hand, those
> branches would be otherwise predicted well, so it might make little or
> no difference.
If you were going to do this, maybe you could encode NULL directly in
an abbreviated key. I think that that could be made to work if it was
limited to opclasses with abbreviated keys encoded as unsigned
integers. Just a thought.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | osumi.takamichi@fujitsu.com | 2022-01-19 03:22:08 | RE: Skipping logical replication transactions on subscriber side |
| Previous Message | Tom Lane | 2022-01-19 02:50:07 | Re: Adding CI to our tree |