| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com> |
| Subject: | Re: Should we optimize the `ORDER BY random() LIMIT x` case? |
| Date: | 2025-05-16 21:42:59 |
| Message-ID: | 8622ae44-7d37-4c6a-a52c-54ba738e5de0@postgresfriends.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16/05/2025 23:21, Tom Lane wrote:
> Vik Fearing <vik(at)postgresfriends(dot)org> writes:
>> On 16/05/2025 15:01, Tom Lane wrote:
>>> Seems to me the obvious answer is to extend TABLESAMPLE (or at least, some
>>> of the tablesample methods) to allow it to work on a subquery.
>> Isn't this a job for <fetch first clause>?
>> FETCH SAMPLE FIRST 10 ROWS ONLY
> How is that an improvement on TABLESAMPLE? Or did the committee
> forget that they already have that feature?
>
> TABLESAMPLE seems strictly better to me here because it affords
> the opportunity to specify one of several methods, which seems
> like it would be useful in this context.
TABLESAMPLE is hitched to a <table primary> which can be basically
anything resembling a relation. So it appears the standard already
allows this and we just need to implement it.
--
Vik Fearing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nico Williams | 2025-05-16 21:50:49 | Re: Should we optimize the `ORDER BY random() LIMIT x` case? |
| Previous Message | Tom Lane | 2025-05-16 21:21:08 | Re: Should we optimize the `ORDER BY random() LIMIT x` case? |