| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tv(at)fuzzy(dot)cz> |
| Subject: | Re: Use generation context to speed up tuplesorts |
| Date: | 2022-04-24 00:59:38 |
| Message-ID: | 20220424005938.GA1319606@rfd.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 01, 2022 at 10:00:08PM +1300, David Rowley wrote:
> 0002:
> This modifies the tuplesort API so that instead of having a
> randomAccess bool flag, this is changed to a bitwise flag that we can
> add further options in the future. It's slightly annoying to break
> the API, but it's not exactly going to be hard for people to code
> around that.
For what it's worth, the three PGXN extensions using tuplesort_begin_* are
"citus", "pg_bulkload", and "vector". Nothing calls tuplesort_set_bound().
This (commit 77bae39) did not change function parameter counts, and
TUPLESORT_RANDOMACCESS generally has same the same numeric value as "true". I
get no warning if I pass "true" for the "sortopt" flags parameter. Hence, I
suspect this did not break the API. Should we be happy about that? I'm fine
with it.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2022-04-24 01:11:45 | Re: Use generation context to speed up tuplesorts |
| Previous Message | Daniel Gustafsson | 2022-04-23 21:40:19 | Re: Cryptohash OpenSSL error queue in FIPS enabled builds |