On 2022-08-27 16:48, Bharath Rupireddy wrote:
On Fri, Aug 26, 2022 at 8:39 AM Kyotaro Horiguchi
wrote:
At Fri, 26 Aug 2022 11:55:27 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 25 Aug 2022 16:04:50 +0900, Ken Kato wrote
in
> > Accumulating the values, which indicates how much space i
On Fri, Aug 26, 2022 at 8:39 AM Kyotaro Horiguchi
wrote:
>
> At Fri, 26 Aug 2022 11:55:27 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Thu, 25 Aug 2022 16:04:50 +0900, Ken Kato
> > wrote in
> > > Accumulating the values, which indicates how much space is saved by
> > > each compression (si
> On 25 Aug 2022, at 12:04, Ken Kato wrote:
>
> What do you think?
I think users will need to choose between Lz4 and Zstd. So they need to know
tradeoff - compression ratio vs cpu time spend per page(or any other segment).
I know that Zstd must be kind of "better", but doubt it have enough
At Fri, 26 Aug 2022 11:55:27 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 25 Aug 2022 16:04:50 +0900, Ken Kato wrote
> in
> > Accumulating the values, which indicates how much space is saved by
> > each compression (size before compression - size after compression),
> > and keep track of
At Thu, 25 Aug 2022 16:04:50 +0900, Ken Kato wrote
in
> Accumulating the values, which indicates how much space is saved by
> each compression (size before compression - size after compression),
> and keep track of how many times compression has happened. So that one
> can know how much space is
Hi hackers,
We can specify compression method (for example, lz4, zstd), but it is
hard to know the effect of compression depending on the method. There is
already a way to know the compression effect using pg_waldump. However,
having these statistics in the view makes it more accessible. I a
