On Fri, 1 Oct 2021 at 13:37, Amit Langote wrote:
> > I've attached a patch that updates the comments to mention this.
>
> Looks good to me. Thanks.
Thanks. Pushed.
David
On Fri, Oct 1, 2021 at 7:07 AM David Rowley wrote:
> On Thu, 30 Sept 2021 at 20:25, Amit Langote wrote:
> > Related to the above, I noticed while looking at
> > build_merged_partition_bounds() that db632fbca3 missed adding a line
> > to that function to set interleaved_parts to NULL. Because the
On Thu, 30 Sept 2021 at 20:25, Amit Langote wrote:
> Related to the above, I noticed while looking at
> build_merged_partition_bounds() that db632fbca3 missed adding a line
> to that function to set interleaved_parts to NULL. Because the
> PartitionBoundInfo is only palloc'd (not palloc0'd), inte
Hi David,
On Mon, Aug 2, 2021 at 11:59 AM Amit Langote wrote:
> On Sun, Aug 1, 2021 at 9:31 PM David Rowley wrote:
> > On Fri, 30 Jul 2021 at 19:10, Amit Langote wrote:
> > > interleaved_parts idea looks clever. I wonder if you decided that
> > > it's maybe not worth setting that field in the
On Mon, 2 Aug 2021 at 20:16, David Rowley wrote:
> If anyone has any objections to both the v4 0001 and 0002 patch, can
> they let me know soon. I'm currently seeing no reason that they can't
> go in.
I've now pushed both of these. Thanks for the reviews.
David
On Mon, 2 Aug 2021 at 00:31, David Rowley wrote:
> I had another self review of these and I'm pretty happy with them. I'm
> quite glad to see the performance of querying a single partition of a
> table with large numbers of partitions no longer tails off as much as
> it used to.
I did some profil
On Sun, Aug 1, 2021 at 9:31 PM David Rowley wrote:
> On Fri, 30 Jul 2021 at 19:10, Amit Langote wrote:
> > 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 yo
Thanks for having a look at this.
On Mon, 2 Aug 2021 at 02:33, Zhihong Yu wrote:
> Here we look for partitions which
> +* might be interleaved with other partitions and set the
> +* interleaved_parts field with the partition indexes of any partitions
> +* which may be interleaved with
On Sun, Aug 1, 2021 at 5:31 AM David Rowley wrote:
> On Fri, 30 Jul 2021 at 19:10, Amit Langote
> wrote:
> >
> > 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 wit
On Fri, 30 Jul 2021 at 19:10, Amit Langote wrote:
>
> 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; /*
On Mon, Jul 12, 2021 at 11:47 AM David Rowley 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;
On Sat, 10 Jul 2021 at 03:24, David Rowley wrote:
> The good news is that the code in partitions_are_ordered() became even
> more simple as a result of this change. We can do ordered scan simply
> when !bms_overlap(live_parts, boundinfo->interleaved_parts).
I've spent a bit more time revising the
On Thu, 1 Jul 2021 at 17:49, Amit Langote wrote:
> Given that you're proposing more uses for live_parts, maybe he'd be
> open to the idea.
Just to make sure the new field in the 0001 patch gets good enough
use, I've attached the patch which includes more usages of the field.
0002 adds a new fiel
On Wed, Jun 30, 2021 at 10:59 PM David Rowley wrote:
> Back when working on 959d00e9d, to allow ordered partition scans for
> LIST and RANGE partitioned tables, I mentioned [1] that if we had a
> field that recorded a Bitmapset of the non-pruned partitions, we could
> use that to do a more thoroug
14 matches
Mail list logo
