| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: bad estimation together with large work_mem generates terrible slow hash joins |
| Date: | 2014-09-10 19:34:03 |
| Message-ID: | CA+TgmoaFCFb521_svu5se=199sKtNpHdwRc34y6OedaSAdPy=A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 10, 2014 at 3:12 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> On 10.9.2014 20:25, Heikki Linnakangas wrote:
>> On 09/10/2014 01:49 AM, Tomas Vondra wrote:
>>> I also did a few 'minor' changes to the dense allocation patch, most
>>> notably:
>>>
>>> * renamed HashChunk/HashChunkData to MemoryChunk/MemoryChunkData
>>> The original naming seemed a bit awkward.
>>
>> That's too easy to confuse with regular MemoryContext and AllocChunk
>> stuff. I renamed it to HashMemoryChunk.
>
> BTW this breaks the second patch, which is allocating new chunks when
> resizing the hash table. Should I rebase the patch, or can the commiter
> do s/MemoryChunk/HashMemoryChunk/ ?
>
> Assuming there are no more fixes needed, of course.
Rebasing it will save the committer time, which will increase the
chances that one will look at your patch. So it's highly recommended.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-09-10 19:37:22 | Re: SKIP LOCKED DATA (work in progress) |
| Previous Message | Heikki Linnakangas | 2014-09-10 19:32:59 | Re: inherit support for foreign tables |