Re: Record a Bitmapset of non-pruned partitions

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Record a Bitmapset of non-pruned partitions
Date: 2021-07-30 07:10:37
Message-ID: CA+HiwqFDo3JTKfF+7uPrkrgKYz9XWn9BORaTmY0MH13Fvn7j+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 12, 2021 at 11:47 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> v3 patches

0001 looks mostly fine, except I thought the following could be worded
to say that the bitmap members are offsets into the part_rels array.
To avoid someone confusing them with RT indexes, for example.

+ Bitmapset *live_parts; /* Bitmap with members to indicate which
+ * partitions survived partition pruning. */

On 0002:

interleaved_parts idea looks clever. I wonder if you decided that
it's maybe not worth setting that field in the joinrel's
PartitionBoundInfos? For example, adding the code that you added in
create_list_bounds() also in merge_list_bounds().

... The definition of interleaved
+ * is any partition that can contain multiple different values where exists at
+ * least one other partition which could contain a value which is between the
+ * multiple possible values in the other partition.

The sentence sounds a bit off starting at "...where exists". How about:

"A partition is considered interleaved if it contains multiple values
such that there exists at least one other partition containing a value
that lies between those values [ in terms of partitioning-defined
ordering ]."

Looks fine otherwise.

--
Amit Langote
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-07-30 07:10:49 Re: A qsort template
Previous Message Greg Nancarrow 2021-07-30 06:52:08 Re: Parallel Inserts (WAS: [bug?] Missed parallel safety checks..)