> Michael Contzen <mcontzen@dohle.com> writes:
> > (using snapshot of May, 5th)
> > because we have the need to have a workaround to this hash problem, I
> > looked into the hashing code (well, without having the background).
> > For reducing the probability of an overflow I increased
> > #define FUDGE_FAC 3
> > witch was originally 1.5.
>
> For a given -B setting, that would mean that more of the hashtable space
> is reserved for overflow records and less for hashbuckets, which should
> reduce the probability of an overrun --- but it would also make the
> system more prone to decide that it needs to divide the hash merge into
> "batches", so performance will suffer. Still, it seems like a
> reasonable workaround until a proper fix can be made. In fact I think
> maybe I should change FUDGE_FAC to 2.0 for the 6.5 release, as a stopgap
> measure...
>
> A more critical problem is that there were some severe bugs in the code
> for handling batches. I fixed at least some of 'em, but I committed
> those fixes on the evening of 5 May, so I suspect they are not in your
> snapshot. (Check the date of src/backend/executor/nodeHash.c to see.)
One thing to consider. If you decide to wait on the patch until after
6.5, but then we find the new optimizer is causing this bug too often,
we will have to fix it later in the beta cycle with less testing time
available.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
