Re: bad estimation together with large work_mem generates terrible slow hash joins
| От | Tom Lane |
|---|---|
| Тема | Re: bad estimation together with large work_mem generates terrible slow hash joins |
| Дата | |
| Msg-id | 16746.1410444705@sss.pgh.pa.us обсуждение |
| Ответ на | Re: bad estimation together with large work_mem generates terrible slow hash joins (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: bad estimation together with large work_mem generates
terrible slow hash joins
Re: bad estimation together with large work_mem generates terrible slow hash joins |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Sep 11, 2014 at 9:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> (3) It allows the number of batches to increase on the fly while the
>>> hash join is in process.
>> Pardon me for not having read the patch yet, but what part of (3)
>> wasn't there already?
> EINSUFFICIENTCAFFEINE.
> It allows the number of BUCKETS to increase, not the number of
> batches. As you say, the number of batches could already increase.
Ah. Well, that would mean that we need a heuristic for deciding when to
increase the number of buckets versus the number of batches ... seems
like a difficult decision.
regards, tom lane
В списке pgsql-hackers по дате отправления: