2008/1/29, Vlad Marchenko <marchenko@xxxxxxxxx>:> 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, What happens if you run the 8.3 test with enable_hashagg set to off? Saudações, Clodoaldo Pinto Neto > ----- Original Message -----> From: "Tom Lane" <tgl@xxxxxxxxxxxxx>> To: "Vlad" <marchenko@xxxxxxxxx>> Cc: "PG-General" <pgsql-general@xxxxxxxxxxxxxx>> Sent: Monday, January 28, 2008 9:13 PM> Subject: Re: 8.3RC2 vs 8.2.6 testing results>>> > Vlad <marchenko@xxxxxxxxx> 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> >>>> ---------------------------(end of broadcast)---------------------------> TIP 5: don't forget to increase your free space map settings> ---------------------------(end of broadcast)---------------------------TIP 6: explain analyze is your friend
