From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Tomas Vondra <tomas(dot)vondra(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DBT-3 with SF=20 got failed |
Date: | 2015-08-19 13:53:36 |
Message-ID: | 30970.1439992416@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 19 August 2015 at 12:55, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> Please don't be rush. :-)
> Please explain what rush you see?
Yours. You appear to be in a hurry to apply patches that there's no
consensus on.
>> It is not difficult to replace palloc() by palloc_huge(), however, it
>> may lead another problem once planner gives us a crazy estimation.
>> Below is my comment on the another thread.
> Yes, I can read both threads and would apply patches for each problem.
I don't see anything very wrong with constraining the initial allocation
to 1GB, or even less. That will prevent consuming insane amounts of
work_mem when the planner's rows estimate is too high rather than too low.
And we do have the ability to increase the hash table size on the fly.
The real problem here is the potential integer overflow in
ExecChooseHashTableSize. Now that we know there is one, that should be
fixed (and not only in HEAD/9.5). But I believe Kaigai-san withdrew his
initial proposed patch, and we don't have a replacement as far as I saw.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-08-19 14:08:24 | Re: Make HeapTupleSatisfiesMVCC more concurrent |
Previous Message | Andres Freund | 2015-08-19 13:46:34 | Re: Proposal: Implement failover on libpq connect level. |