On Fri, Sep 27, 2013 at 4:44 AM, Robert Haas <[email protected]> wrote:
> On Wed, Sep 25, 2013 at 4:46 AM, David Rowley <[email protected]> > wrote: > > Ok, I think I've managed to narrow the performance gap to just about > nothing > > but noise, though to do this the code is now a bit bigger. I've added a > > series of tests to see if the padding is > 0 and if it's not then I'm > doing > > things the old way. > > > > I've also added a some code which does a fast test to see if it is worth > > while calling the padding processing function. This is just a simple if > (*p > > <= '9'), I'm not completely happy with that as it does look a bit weird, > but > > to compensate I've added a good comment to explain what it is doing. > > > > Please find attached the new patch ... version v0.5 and also updated > > benchmark results. > > Are you sure this is the right set of benchmark results? This still > reflects a 15-18% slowdown AFAICS. > > I think I must have forgot to save it before I emailed it... Here's the correct version. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
log_line_prefix_benchmark_stresslog_v0.5.xls
Description: MS-Excel spreadsheet
-- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
