Re: bad estimation together with large work_mem generates terrible slow hash joins
От | Robert Haas |
---|---|
Тема | Re: bad estimation together with large work_mem generates terrible slow hash joins |
Дата | |
Msg-id | CA+TgmoaFCFb521_svu5se=199sKtNpHdwRc34y6OedaSAdPy=A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: bad estimation together with large work_mem generates terrible slow hash joins (Tomas Vondra <tv@fuzzy.cz>) |
Ответы |
Re: bad estimation together with large work_mem generates
terrible slow hash joins
|
Список | pgsql-hackers |
On Wed, Sep 10, 2014 at 3:12 PM, Tomas Vondra <tv@fuzzy.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
В списке pgsql-hackers по дате отправления: