> 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
> important than DDL, but I think the same results would apply here, so I think
> it's not needed to test each of LIST/RANGE/HASH, nor to test every combination
> of patches.
Yes. I also feel that the same result would apply there as well.
> Note that for the MAXRSS test, you must a different postgres backend process
> for each of the tests (or else each test would never show a lower number than
> the previous test).
I have used different backend processes for each of the tests.
> Mostly it's nice to see if the memory use is more visibly
> different, or if there's an impressive improvement for this case.
I did not get this point. Kindly explain for which scenario the memory
usage test has to be done.
Thanks & Regards,
Nitin Jadhav
On Sun, May 23, 2021 at 11:16 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> 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.5464 17.8655 17.5069
>
> For anyone reading non-HTML email, the last line shows the averages of the
> previous 10 lines.
>
> >> LIST and RANGE might need to be checked separately..
>
> You checked LIST but not HASH (patches 3-4) or RANGE (patch 4-5), right?
>
> Another test is to show the time/memory used by SELECT. That's far more
> important than DDL, but I think the same results would apply here, so I think
> it's not needed to test each of LIST/RANGE/HASH, nor to test every combination
> of patches. Mostly it's nice to see if the memory use is more visibly
> different, or if there's an impressive improvement for this case.
>
> Note that for the MAXRSS test, you must a different postgres backend process
> for each of the tests (or else each test would never show a lower number than
> the previous test).
>
> Thanks,
> --
> Justin
