Re: Compress ReorderBuffer spill files using LZ4
От | Amit Kapila |
---|---|
Тема | Re: Compress ReorderBuffer spill files using LZ4 |
Дата | |
Msg-id | CAA4eK1Kd6vP1g5pJXoiPgfLQsn54hecsc06hxpNWV-9_xMa+5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Compress ReorderBuffer spill files using LZ4 (Julien Tachoires <julmon@gmail.com>) |
Ответы |
Re: Compress ReorderBuffer spill files using LZ4
Re: Compress ReorderBuffer spill files using LZ4 Re: Compress ReorderBuffer spill files using LZ4 |
Список | pgsql-hackers |
On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires <julmon@gmail.com> wrote: > > When the content of a large transaction (size exceeding > logical_decoding_work_mem) and its sub-transactions has to be > reordered during logical decoding, then, all the changes are written > on disk in temporary files located in pg_replslot/<slot_name>. > Decoding very large transactions by multiple replication slots can > lead to disk space saturation and high I/O utilization. > Why can't one use 'streaming' option to send changes to the client once it reaches the configured limit of 'logical_decoding_work_mem'? > > 2. Do we want a GUC to switch compression on/off? > It depends on the overhead of decoding. Did you try to measure the decoding overhead of decompression when reading compressed files? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: