Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]

От: Stefan Kaltenbrunner
Тема: Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]
Дата: ,
Msg-id: 45EF090C.6070503@kaltenbrunner.cc
(см: обсуждение, исходный текст)
Ответ на: Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

[kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  ("Jim C. Nasby", )
 Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Alvaro Herrera, )
  Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Arjen van der Meijden, )
   Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Arjen van der Meijden, )
    Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Stefan Kaltenbrunner, )
     Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Arjen van der Meijden, )
      Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Stefan Kaltenbrunner, )
       Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Tom Lane, )
        Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Arjen van der Meijden, )
        Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Stefan Kaltenbrunner, )
    Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Richard Huxton, )
  Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]  (Scott Marlowe, )

Tom Lane wrote:
> Stefan Kaltenbrunner <> writes:
>> Arjen van der Meijden wrote:
>>> Stefan Kaltenbrunner wrote:
>>>> ouch - do I read that right that even after tom's fixes for the
>>>> "regressions" in 8.2.0 we are still 30% slower then the -HEAD checkout
>>>> from the middle of the 8.2 development cycle ?
>>> Yes, and although I tested about 17 different cvs-checkouts, Tom and I
>>> weren't really able to figure out where "it" happened. So its a bit of a
>>> mystery why the performance is so much worse.
>
>> double ouch - losing that much in performance without an idea WHY it
>> happened is really unfortunate :-(
>
> Keep in mind that Arjen's test exercises some rather narrow scenarios;
> IIRC its performance is mostly determined by some complicated
> bitmap-indexscan cases.  So that "30% slower" bit certainly doesn't
> represent an across-the-board figure.  As best I can tell, the decisions
> the planner happened to be making in late June were peculiarly nicely
> suited to his test, but not so much for other cases.

understood - I was not trying to imply that we suffer a 30% performance
drop overall.
But still it means we know about a set of queries that we once could
handle faster than we can now ...

Stefan


В списке pgsql-performance по дате сообщения:

От: Zoolin Lin
Дата:
Сообщение: Re: Any advantage to integer vs stored date w. timestamp
От: Shane Ambler
Дата:
Сообщение: Re: Any advantage to integer vs stored date w. timestamp