Re: Hash Join node sometimes slow

Поиск
Список
Период
Сортировка
От Dave Roberge
Тема Re: Hash Join node sometimes slow
Дата
Msg-id C4ABE222F455C04FB64CC3B7147428894261ACEE@ORD2MBX01C.mex05.mlsrvr.com
обсуждение исходный текст
Ответ на Re: Hash Join node sometimes slow  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Tom Lane writes:
> I'd bet on the extra time being in I/O for the per-batch temp files, since it's hard
> to see what else would be different if the data were identical in each run.
> Maybe the kernel is under memory pressure and is dropping the file data from
> in-memory disk cache.  Or maybe it's going to disk all the time but the slow runs
> face more I/O congestion.
>
> Personally, for a problem of this size I'd increase work_mem enough so you
> don't get multiple batches in the first place.

Tom thanks for the response. I'm very much a novice in this area - what do you mean by problem of this size, i.e.
numberof rows, hash memory usage? Does 'shared read' mean either 1) it was read from disk or 2) it was read from
in-memorydisk cache? 


В списке pgsql-performance по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Postgres Replaying WAL slowly
Следующее
От: "Huang, Suya"
Дата:
Сообщение: DB sessions 100 times of DB connections