From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Clodoaldo <clodoaldo(dot)pinto(dot)neto(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, PostgreSQL - General ML <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4? |
Date: | 2008-01-20 10:36:24 |
Message-ID: | 20080120103624.GA9599@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Jan 19, 2008 at 10:33:00PM -0500, Tom Lane wrote:
> The difference comes from the fact that the HashAggregate step --- which
> is being done on hashing columns (data, usuario) --- is effectively
> reading out in hash-value order for usuario, meaning that that is the
> order in which we make index insertions. 8.2 had an extremely chintzy
> hash function for integers --- basically just return the negative of the
> integer value --- while 8.3 takes it seriously and produces a nicely
> randomized hash value. This means that the usuario values are returned
> in a relatively well ordered fashion in 8.2 and a nearly totally random
> one in 8.3.
A random thought: Is there not some way of representing this difference
in the planner? We store the correlation for tables, could it not be
argued that the output of a hash plan is correlation zero, whereas an
indexscan may have higher correlation... A low correlation works
against plans returning lots of rows.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy
From | Date | Subject | |
---|---|---|---|
Next Message | Clodoaldo | 2008-01-20 11:29:16 | Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4? |
Previous Message | Simon Riggs | 2008-01-20 09:19:46 | Re: WARNINGs after starting backup server created with PITR |