Re: PATCH: Using BRIN indexes for sorted output

On 10/16/22 03:36, Zhihong Yu wrote:
>
>
> On Sat, Oct 15, 2022 at 8:23 AM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com <mailto:tomas(dot)vondra(at)enterprisedb(dot)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 <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.
>

No, because the "mark_processed" may be false. So we may not mark it as
processed in some cases.

> 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.
>

We could/should, although most of the loops should be very short.

regrds

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