Re: 8.3RC2 vs 8.2.6 testing results
От | Vlad Marchenko |
---|---|
Тема | Re: 8.3RC2 vs 8.2.6 testing results |
Дата | |
Msg-id | D790CC4FA7C842E6BB9BB6A5BBEBC973@vladm обсуждение исходный текст |
Ответ на | 8.3RC2 vs 8.2.6 testing results (Vlad <marchenko@gmail.com>) |
Ответы |
Re: 8.3RC2 vs 8.2.6 testing results
Re: 8.3RC2 vs 8.2.6 testing results |
Список | pgsql-general |
Tom: Yes, they are ints. To (somewhat) check your guess on the role of the hash aggregation speed, I just ran oltp test from sysbench (http://sysbench.sourceforge.net/docs/#database_mode) on a table with 1mln of records. That test uses pretty simple queries (that do not use aggregation) and 8.3 showed about the same performance as 8.2 (strictly speaking 8.3 was about 1-2% slower, but not 10-15% like on my query). I'm curious if that new hash aggregation algorithm was put in 8.3 with the performance increase as a goal or it was simply a required change to support some other new feature of 8.3? Right now the switch from 8.2 to 8.3 doesn't seems a favorable step for the type of application that we have... -- vlad ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Vlad" <marchenko@gmail.com> Cc: "PG-General" <pgsql-general@postgresql.org> Sent: Monday, January 28, 2008 9:13 PM Subject: Re: [GENERAL] 8.3RC2 vs 8.2.6 testing results > Vlad <marchenko@gmail.com> writes: >> 2. We ran several tests and found 8.3 generally 10% slower than 8.2.6. > > The particular case you are showing here seems to be all about the speed > of hash aggregation --- at least the time differential is mostly in the > HashAggregate step. What is the data type of a_id? I speculate that > you're noticing the slightly slower/more complicated hash function that > 8.3 uses for integers. On a case where the data was well distributed > you'd not see any countervailing efficiency gain from those extra > cycles. > > regards, tom lane >
В списке pgsql-general по дате отправления: