Re: [HACKERS] Hashjoin status report
| От | Michael Contzen |
|---|---|
| Тема | Re: [HACKERS] Hashjoin status report |
| Дата | |
| Msg-id | 01be9871$fa35aa60$4dbe7fc2@wcontzen.dohle.com обсуждение исходный текст |
| Ответы |
Re: [HACKERS] Hashjoin status report
|
| Список | pgsql-hackers |
Hello,
(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. I think it´s a data dependend constant (correct?) and for my data it works...
It does the job, but certainly that this is not the solution.
Increasing -B 256 doesn´t work:
NOTICE: Buffer Leak: [248] (freeNext=0, freePrev=0, relname=, blockNum=0, flags=0x0, refcount=0 25453)
pq_flush: send() failed, errno 88
pq_recvbuf: recv() failed, errno=88
pq_flush: send() failed, errno 88
pq_recvbuf: recv() failed, errno=88
Kind regards,
Michael Contzen
Dohle Systemberatung, Germany
Kind regards,
Michael Contzen
Dohle Systemberatung, Germany
В списке pgsql-hackers по дате отправления: