Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Date
Msg-id 20140421161151.GG14024@alap3.anarazel.de
Whole thread Raw
In response to Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-04-21 11:58:10 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-04-21 11:45:49 -0400, Andrew Dunstan wrote:
> >> That seems to make more sense. I can't imagine why this would be a runtime
> >> parameter as opposed to build time.
> 
> > Because that implies that packagers and porters need to make that
> > decision. If it's a GUC people can benchmark it and decide.
> 
> As against that, the packager would be more likely to get it right
> (or even to know that there's an issue).

I sure hope that FreeBSD is going to fix this at some point (it's surely
affecting more than just postgres). But since we (and probably the
packagers) don't know which platforms it's going to affect the only
thing we could do would be to add a configure switch. To test people
would need to recompile postgres.
I don't understand what the problem with a GUC here is. It's a pretty
simple patch and that codepath is entered only once, so performance
surely can't be an argument.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Next
From: Merlin Moncure
Date:
Subject: Re: Composite Datums containing toasted fields are a bad idea(?)