pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Zhihong Yu <zyu@yugabyte.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PATCH: Using BRIN indexes for sorted output
Date: Sun, 16 Oct 2022 16:14:32 +0200
Message-ID: <3b7f45c8-5b95-7c74-13cf-a58cb44c1de1@enterprisedb.com> (raw)
In-Reply-To: <CALNJ-vS=mMT+Km3FAfbzYCn-vQKNk5inHCUfTYi4rD8DJfG1vg@mail.gmail.com>
References: <e70fa091-e338-1598-9de4-6d0ef6b693e2@enterprisedb.com>
	<CALNJ-vTA-QvA3bQYwTuv6euzt1kXb4kcTHuRnpwE8gfg4YTrFw@mail.gmail.com>
	<c83596b3-994e-a32b-598a-efcbd99ef58a@enterprisedb.com>
	<CALNJ-vS=mMT+Km3FAfbzYCn-vQKNk5inHCUfTYi4rD8DJfG1vg@mail.gmail.com>



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





view thread (60+ messages)  latest in thread

Message-ID: <3b7f45c8-5b95-7c74-13cf-a58cb44c1de1@enterprisedb.com>
Permalink:  ../3b7f45c8-5b95-7c74-13cf-a58cb44c1de1@enterprisedb.com/
Also on:    postgresql.org/message-id/3b7f45c8-5b95-7c74-13cf-a58cb44c1de1@enterprisedb.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@enterprisedb.com, zyu@yugabyte.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: PATCH: Using BRIN indexes for sorted output
  In-Reply-To: <3b7f45c8-5b95-7c74-13cf-a58cb44c1de1@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox