On Tue, Jul 25, 2017 at 1:31 AM, Rafia Sabih <rafia.sa...@enterprisedb.com> wrote: > - other queries show a good 20-30% improvement in performance. Performance > numbers are as follows, > > Query| un_part_head (seconds) | part_head (seconds) | part_patch (seconds) | > 3 | 76 |127 | 88 | > 4 |17 | 244 | 41 | > 5 | 52 | 123 | 84 | > 7 | 73 | 134 | 103 | > 10 | 67 | 111 | 89 | > 12 | 53 | 114 | 99 | > 18 | 447 | 709 | 551 |
Hmm. This certainly shows that benefit of the patch, although it's rather sad that we're still slower than if we hadn't partitioned the data in the first place. Why does partitioning hurt performance so much? Maybe things would be better at a higher scale factor. When reporting results of this sort, it would be good to make a habit of reporting the number of partitions along with the other details you included. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
