> 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 <pry...@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
