Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Поиск
Список
Период
Сортировка
От Alfred Perlstein
Тема Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Дата
Msg-id 53557130.6090806@freebsd.org
обсуждение исходный текст
Ответ на Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 4/21/14, 11:14 AM, Stephen Frost wrote:
> Alfred,
>
> * Alfred Perlstein (alfred@freebsd.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: assertion failure 9.3.4
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: assertion failure 9.3.4