Re: Is there any chance to get some kind of a result set sifting mechanism in Postgres?

From: Wolfgang Wilhelm <wolfgang20121964(at)yahoo(dot)de>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, aa <ghevge(at)gmail(dot)com>
Subject: Re: Is there any chance to get some kind of a result set sifting mechanism in Postgres?
Date: 2024-05-13 09:48:34
Message-ID: 1620765473.2321666.1715593714608@mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
do I interpret your idea correctly: You want some sort of ordering without ordering?
Kind regardsWW

Am Montag, 13. Mai 2024 um 10:40:38 MESZ hat aa <ghevge(at)gmail(dot)com> Folgendes geschrieben:

Hello Everyone!
Is there any chance to get some kind of a result set sifting mechanism in Postgres? 
What I am looking for is a way to get for example: "nulls last" in a result set, without having to call "order by" or having to use UNION ALL, and if possible to get this in a single result set pass.
Something on this line: SELECT a, b, c FROM my_table WHERE a nulls last OFFSET 0 LIMIT 25
I don't want to use order by or union all because these are time consuming operations, especially on  large data sets and when comparations are done on dynamic values (eg: geolocation distances in between a mobile and a static location) 
What I would expect from such a feature, will be speeds comparable with non sorted selects, while getting a very rudimentary ordering.
A use case for such a mechanism will be the implementation of QUICK relevant search results for a search engine.
I'm not familiar with how Postgres logic handles simple select queries, but the way I would envision a result set sifting logic, would be to collect the result set, in 2 separate lists, based on the sifting condition, and then concatenate these 2 lists and return the result, when the pagination requests conditions are met.
Any idea if such a functionality is feasible ?
Thank you.
  PS: if ever implemented, the sifting mechanism could be extended to accommodate any type of thresholds, not just null values.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anton Voloshin 2024-05-13 09:49:54 Re: 039_end_of_wal: error in "xl_tot_len zero" test
Previous Message Dmitry Koval 2024-05-13 09:45:49 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands