On Thu, Oct 2, 2014 at 5:08 PM, Greg Smith
<greg.smith@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
