Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

From: Alfred Perlstein <alfred(at)freebsd(dot)org>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Date: 2014-04-21 19:27:44
Message-ID: 53557130.6090806@freebsd.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 4/21/14, 11:14 AM, Stephen Frost wrote:
> Alfred,
>
> * Alfred Perlstein (alfred(at)freebsd(dot)org) wrote:
>> On 4/21/14, 9:51 AM, Andres Freund wrote:
>>> On 2014-04-21 09:42:06 -0700, Alfred Perlstein wrote:
>>>> Sure, to be fair, we are under the gun here for a product, it may just mean
>>>> that the end result of that conversation is "mysql".
>>> Personally arguments in that vain are removing just about any incentive
>>> I have to work on the problem.
>> I was just explaining that we have a timeline over here and while
>> that may disincentive you for providing what we need it would be
>> very unfair.
> I'm pretty sure Andres was referring to the part where there's a
> 'threat' to move to some other platform due to a modest performance
> degredation, as if it's the only factor involved in making a decision
> among the various RDBMS options. If that's really your deciding
> criteria instead of the myriad of other factors, I daresay you have your
> priorities mixed up.
>
>> There are other Linux centric dbs to pick from. If pgsql is just
>> another Linux centric DB then that is unfortunate but something I
>> can deal with.
> These attacks really aren't going to get you anywhere. We're talking
> about a specific performance issue that FreeBSD has and how much PG
> (surely not the only application impacted by this issue) should bend
> to address it, even though the FreeBSD folks were made aware of the
> issue over year ago and have done nothing to address it.
>
> Moreover, you'd like to also define the way we deal with the issue as
> being to make it runtime configurable rather than as a compile-time
> option, even though 90% of the users out there won't understand the
> difference nor would know how to correctly set it (and, in many cases,
> may end up making the wrong decision because it's the default for
> other platforms, unless we add more code to address this at initdb
> time).
>
> Basically, it doesn't sound like you're terribly concerned with the
> majority of our user base, even on FreeBSD, and would prefer to try
> and browbeat us into doing what you've decided is the correct solution
> because it'd work better for you.
>
> I've been guiltly of the same in the past and it's not fun having to
> back off from a proposal when it's pointed out that there's a better
> option, particularly when it doesn't seem like the alternative is
> better for me, but that's just part of working in any large project.
>
Stephen, please calm down on the hyperbole, seriously, picking another
db is not an attack.

I was simply asking for a feature that would make my life easier as both
an admin deploying postgresql and a kernel dev attempting to fix a
problem. I'm one guy, probably the only guy right now asking. Honestly
the thought of needing to compile two versions of postgresql to do sysv
vs mmap performance would take me more time than I would like to devote
to the issue when my time is already limited.

Again, it was an ask, you are free to do what you like, the same way you
were free to ignore my advice at pgcon about mmap being less efficient.
It does not make what I'm saying an "attack". Just like when
interviewing people choosing a different candidate for a job is not an
attack on the other candidates!

-Alfred

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-04-21 19:31:09 Re: assertion failure 9.3.4
Previous Message Tom Lane 2014-04-21 19:26:03 Re: assertion failure 9.3.4