On Tue, 6 Jul 2021 at 05:03, Justin Pryzby wrote:
>
> Also, if you're going to remove the initializations here, maybe you'd also
> change i and j to C99 "for" declarations like "for (int i=0, j=0; ...)"
>
> - PartitionListValue **all_values = NULL;
> - ListCell *cell;
> - int
On Tue, 6 Jul 2021 at 04:45, Justin Pryzby wrote:
> If you wanted to further squish the patches together, I don't mind being a
> co-author.
Thanks for looking at the patches.
I fixed the couple of things that you mentioned and pushed all 4
patches as a single commit (53d86957e)
David
Also, if you're going to remove the initializations here, maybe you'd also
change i and j to C99 "for" declarations like "for (int i=0, j=0; ...)"
- PartitionListValue **all_values = NULL;
- ListCell *cell;
- int i = 0;
- int ndatum
On Tue, Jul 06, 2021 at 01:48:52AM +1200, David Rowley wrote:
> On Wed, 19 May 2021 at 05:28, Nitin Jadhav
> wrote:
> > I have rebased all the patches on top of
> > 'v2_0001-removed_extra_mem_alloc_from_create_list_bounds.patch'.
> > Attaching all the patches here.
>
> I had a look over these an
On Wed, 19 May 2021 at 05:28, Nitin Jadhav
wrote:
> I have rebased all the patches on top of
> 'v2_0001-removed_extra_mem_alloc_from_create_list_bounds.patch'.
> Attaching all the patches here.
I had a look over these and I think what's being done here is fine.
I think this will help speed up bu
> You checked LIST but not HASH (patches 3-4) or RANGE (patch 4-5), right?
Yes. I did not check about HASH and RANGE partitioning related patches
as the changes are mostly similar to the list partitioning related
changes.
> Another test is to show the time/memory used by SELECT. That's far more
On Sun, May 23, 2021 at 10:40:16PM +0530, Nitin Jadhav wrote:
> I have used the same testing procedure as explained in the previous mail.
> Please find the timing information of the last 10 creation of partitioned
> tables as given below.
> Without patch With 0001 and 0002 With all patch
...
> 18.
> > I think some of my patches could *increase* memory use, due to
power-of-two
> > allocation logic. I think it's still a good idea, since it doesn't
seem to be
> > the dominant memory allocation.
>
> I don't think that it will increase performance rather it adds to the
improvement.
Sorry. Kindl
> I see this as a code cleanup more than an performance optimization.
I agree with this. This is like a code cleanup but it also improves
performance.
I have done the performance testing, Just to confirm whether it really
improves
performance.
> I think some of my patches could *increase* memory
On Tue, May 18, 2021 at 01:49:12PM -0400, Robert Haas wrote:
> I see that you have made a theoretical argument for why this should be
> good for performance, but it would be better to have some test results
> that show that it works out in practice. Sometimes things seem like
> they ought to be mor
> Created a table with one column of type 'int' and partitioned by that
> column. Created 1 million partitions using following queries.
Sorry. It's not 1 million. Its 10,000 partitions.
--
Thanks & Regards,
Nitin Jadhav
On Thu, May 20, 2021 at 12:21 AM Nitin Jadhav
wrote:
>
> > 'git apply' is v
> 'git apply' is very picky. Use 'patch -p1' to apply your patches instead.
>
> Also, use 'git diff --check' or 'git log --check' before generating
> patches to send, and fix any whitespace errors before submitting.
Thanks for the suggestion. I will follow these.
> I see that you have made a theo
On Tue, May 18, 2021 at 1:29 PM Nitin Jadhav
wrote:
> > The CFBOT had no issues with the patches, so I suspect an issue on your
> > side.
> > http://cfbot.cputube.org/nitin-jadhav.html
>
> I am getting the following error when I try to apply in my machine.
>
> $ git apply
> ../patches/0001-Remov
> The CFBOT had no issues with the patches, so I suspect an issue on your side.
> http://cfbot.cputube.org/nitin-jadhav.html
I am getting the following error when I try to apply in my machine.
$ git apply
../patches/0001-Removed-extra-memory-allocations-from-create_list_bo.patch
../patches/0001-
On Mon, May 17, 2021 at 08:22:25PM +0530, Nitin Jadhav wrote:
> I agree and thanks for creating those patches. I am not able to apply
> the patch on the latest HEAD. Kindly check and upload the modified
> patches.
The CFBOT had no issues with the patches, so I suspect an issue on your side.
http:/
On Mon, May 17, 2021 at 7:52 AM Nitin Jadhav
wrote:
> > > While working on [1], I observed that extra memory is allocated in
> > > [1]
> https://mail.google.com/mail/u/2/#search/multi+column+list/KtbxLxgZZTjRxNrBWvmHzDTHXCHLssSprg?compose=CllgCHrjDqKgWCBNMmLqhzKhmrvHhSRlRVZxPCVcLkLmFQwrccpTpqLNgb
> > While working on [1], I observed that extra memory is allocated in
> > [1]
> > https://mail.google.com/mail/u/2/#search/multi+column+list/KtbxLxgZZTjRxNrBWvmHzDTHXCHLssSprg?compose=CllgCHrjDqKgWCBNMmLqhzKhmrvHhSRlRVZxPCVcLkLmFQwrccpTpqLNgbWqKkTkTFCHMtZjWnV
I am really sorry for this. I wanted
On Sun, May 16, 2021 at 10:00 AM Justin Pryzby wrote:
> On Sat, May 15, 2021 at 02:40:45PM +0530, Nitin Jadhav wrote:
> > While working on [1], I observed that extra memory is allocated in
> > [1]
> https://mail.google.com/mail/u/2/#search/multi+column+list/KtbxLxgZZTjRxNrBWvmHzDTHXCHLssSprg?comp
http://cfbot.cputube.org/
Thanks,
--
Justin
>From eccac01b63c983ba97859a4893e4115de19fda95 Mon Sep 17 00:00:00 2001
From: Nitin Jadhav
Date: Sat, 15 May 2021 14:40:45 +0530
Subject: [PATCH 1/5] Removed extra memory allocations from create_list_bounds
---
src/backend/partitioning/partbounds.c | 6
Hi,
While working on [1], I observed that extra memory is allocated in
'create_list_bounds'
function which can be avoided. So the attached patch removes extra memory
allocations done inside 'create_list_bounds' function and also removes the
unused variable 'cell'.
In the existing code, in create_
20 matches
Mail list logo
