Re: PATCH: Using BRIN indexes for sorted output - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: PATCH: Using BRIN indexes for sorted output
Date
Msg-id CALNJ-vS=mMT+Km3FAfbzYCn-vQKNk5inHCUfTYi4rD8DJfG1vg@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: Using BRIN indexes for sorted output  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: PATCH: Using BRIN indexes for sorted output  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers


On Sat, Oct 15, 2022 at 8:23 AM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
On 10/15/22 15:46, Zhihong Yu wrote:
>...
>     8) Parallel version is not supported, but I think it shouldn't be
>     possible. Just make the leader build the range info, and then let the
>     workers to acquire/sort ranges and merge them by Gather Merge.
> ...
> Hi,
> I am still going over the patch.
>
> Minor: for #8, I guess you meant `it should be possible` .
>

Yes, I meant to say it should be possible. Sorry for the confusion.



regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi,

For brin_minmax_ranges, looking at the assignment to gottuple and reading gottuple, it seems variable gottuple can be omitted - we can check tup directly.

+   /* Maybe mark the range as processed. */
+   range->processed |= mark_processed;

`Maybe` can be dropped.

For brinsort_load_tuples(), do we need to check for interrupts inside the loop ?
Similar question for subsequent methods involving loops, such as brinsort_load_unsummarized_ranges.

Cheers

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: New docs chapter on Transaction Management and related changes
Next
From: Andres Freund
Date:
Subject: Re: Use -fvisibility=hidden for shared libraries