On Sun, Apr 14, 2019 at 3:29 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > What I get for test cases like [1] is > > single-partition SELECT, hash partitioning: > > N tps, HEAD tps, patch > 2 11426.243754 11448.615193 > 8 11254.833267 11374.278861 > 32 11288.329114 11371.942425 > 128 11222.329256 11185.845258 > 512 11001.177137 10572.917288 > 1024 10612.456470 9834.172965 > 4096 8819.110195 7021.864625 > 8192 7372.611355 5276.130161 > > single-partition SELECT, range partitioning: > > N tps, HEAD tps, patch > 2 11037.855338 11153.595860 > 8 11085.218022 11019.132341 > 32 10994.348207 10935.719951 > 128 10884.417324 10532.685237 > 512 10635.583411 9578.108915 > 1024 10407.286414 8689.585136 > 4096 8361.463829 5139.084405 > 8192 7075.880701 3442.542768
I have difficulty interpreting these results in any way other than as an endorsement of the approach that I took. It seems like you're proposing to throw away what is really a pretty substantial amount of performance basically so that the code will look more like you think it should look. But I dispute the idea that the current code is so bad that we need to do this. I don't think that's the case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
