On Tue, Feb 3, 2015 at 4:11 AM, Heikki Linnakangas
wrote:
> On 01/31/2015 01:49 AM, Peter Geoghegan wrote:
>> The refactoring patch certainly looks very reasonable.
>
> Ok, committed the refactoring part for now. Thanks for the review.
Where are we on the rest of this, Heikki?
--
Peter Geoghega
On 01/31/2015 01:49 AM, Peter Geoghegan wrote:
The refactoring patch certainly looks very reasonable.
Ok, committed the refactoring part for now. Thanks for the review.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
On Tue, Nov 18, 2014 at 10:03 AM, Heikki Linnakangas
wrote:
> So there's clearly some room for improvement here. A couple of ideas:
>
> 1. Replace the qsort with something cheaper. The itemid arrays being sorted
> are small, a few hundred item at most, usually even smaller. In this pgbench
> test
On 11/18/2014 07:03 PM, Heikki Linnakangas wrote:
When profiling replay the WAL generated by pgbench, I noticed the
PageRepairFragmentation consumes a large fraction of the CPU time:
[snip]
1. Replace the qsort with something cheaper. The itemid arrays being
sorted are small, a few hundred ite
When profiling replay the WAL generated by pgbench, I noticed the
PageRepairFragmentation consumes a large fraction of the CPU time:
Per "perf report":
+ 33.44% 6.79% postmaster postgres[.]
PageRepairFragmentation
The 33.44% figure includes all the functions called by
Pa
