Ron:
On Fri, 15 Oct 2021 at 20:16, Ron wrote:
> > so no overlap.
> I was afraid you were going to say that. It's completely bizarre, but seems
> to be a "thing" in computer science.
Right half open intervals are normally choosed because they can fully
cover the real line without overlap. Full o
Hello,
I have a table storing mostly text data (40M+ rows) that has
pg_total_relation_size ~670GB.
I’ve just upgraded to postgres 14 and I’m now eager to try the new LZ4
compression.
I’ve altered the column to use the new lz4 compression, but that only applies
to new rows.
What’s the recommen
On 10/17/21 10:12 AM, Florents Tselai wrote:
Hello,
I have a table storing mostly text data (40M+ rows) that has
pg_total_relation_size ~670GB.
I’ve just upgraded to postgres 14 and I’m now eager to try the new LZ4
compression.
I’ve altered the column to use the new lz4 compression, but that
On 10/17/21 11:36 AM, Ron wrote:
On 10/17/21 10:12 AM, Florents Tselai wrote:
Hello,
I have a table storing mostly text data (40M+ rows) that has
pg_total_relation_size ~670GB.
I’ve just upgraded to postgres 14 and I’m now eager to try the new LZ4
compression.
I’ve altered the column to use
On Sun, Oct 17, 2021 at 5:12 PM Florents Tselai
wrote:
> Hello,
>
> I have a table storing mostly text data (40M+ rows) that has
> pg_total_relation_size ~670GB.
> I’ve just upgraded to postgres 14 and I’m now eager to try the new LZ4
> compression.
>
> I’ve altered the column to use the new lz4
On 10/17/21 10:17, Magnus Hagander wrote:
On Sun, Oct 17, 2021 at 5:12 PM Florents Tselai
mailto:florents.tse...@gmail.com>> wrote:
Is there a smarter way to do this ?
It should be enough to VACUUM FULL the table. (but it has to be VACUUM
FULL, not a regular vacuum). Or CLUSTER.
With
Yes, That COPY-delete-COPY sequence is what I ended up doing.
Unfortunately can’t use ranges as the PK its a text string.
> On 17 Oct 2021, at 7:36 PM, Ron wrote:
>
> On 10/17/21 10:12 AM, Florents Tselai wrote:
>> Hello,
>>
>> I have a table storing mostly text data (40M+ rows) that has
>> pg
I did look into VACUUM(full) for it’s PROCESS_TOAST option which makes sense,
but the thing is I already had a cron-ed VACUUM (full) which I ended up
disabling a while back; exactly because of the double-space requirement.
The DB has already a 1TB size and occupying another 600MB would require so
Florents Tselai wrote:
> I have a table storing mostly text data (40M+ rows) that has
> pg_total_relation_size ~670GB.
> I’ve just upgraded to postgres 14 and I’m now eager to try the new LZ4
> compression.
You could start experimenting with data samples rather than the
full contents.
FW
On Sun, Oct 17, 2021 at 10:33:52PM +0200, Daniel Verite wrote:
> However lz4 appears to be much faster to compress than pglz, so its
> benefit is clear in terms of CPU usage for future insertions.
CPU-speaking, LZ4 is *much* faster than pglz when it comes to
compression or decompression with its d
On Sun, Oct 17, 2021 at 10:13:48PM +0300, Florents Tselai wrote:
> I did look into VACUUM(full) for it’s PROCESS_TOAST option which
> makes sense, but the thing is I already had a cron-ed VACUUM (full)
> which I ended up disabling a while back; exactly because of the
> double-space requirement.
Pl
On Sun, 17 Oct 2021 at 21:04, Florents Tselai wrote:
> Yes, That COPY-delete-COPY sequence is what I ended up doing.
> Unfortunately can’t use ranges as the PK its a text string.
Unless you have a really weird PK and have trouble calculating bounds,
text strings are sortable and fine to use as ra
Oh, that’s good to know then. So besides ALTER COMPRESSION for future inserts
there’s not much one can do for pre-existing values
I think it makes sense to update/ add more info to the docs on this as well,
since other people in the thread expected this to work that way too.
Maybe at some point,
13 matches
Mail list logo
