On Thu, Oct 2, 2014 at 5:08 PM, Greg Smith <greg.sm...@crunchydatasolutions.com> wrote: > When 9.4 is already giving a more than 100% gain on this targeted test case, > I can't see that chasing after maybe an extra 10% is worth having yet > another GUC around. Especially when it will probably take multiple tuning > steps before you're done anyway; we don't really know the rest of them yet; > and when we do, we probably won't need a GUC to cope with them in the end > anyway.
Agreed. I think that prior to 9.4, the logging performance of Postgres was very competitive when compared to other systems. At this stage, it's probably extremely fast by any standard. Amit's work on only WAL-logging the modified portion of UPDATEs helps here too. I tend to believe that the next big round of performance gains can be had by working on the buffer manager, and B-Tree indexes. At some point we should work on prefix compression within B-Tree leaf pages. We should also work on adding "abbreviated keys" to B-Tree internal pages. Doing so should almost remove the benefit of using the C locale, because most comparisons needed for index scans can use comparisons implemented as nothing more than a memcmp() (note that internal pages have values that are naturally heterogeneous, so this will work well). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers