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