Re: SUBSTRING performance for large BYTEA - Mailing list pgsql-general

From Tom Lane
Subject Re: SUBSTRING performance for large BYTEA
Date
Msg-id 17525.1187459478@sss.pgh.pa.us
Whole thread Raw
In response to Re: SUBSTRING performance for large BYTEA  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Responses Re: SUBSTRING performance for large BYTEA  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
List pgsql-general
Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> Would it be feasible to add an ALTER TABLE mode
>     ... set storage externally-extended cutoff <size> ...
> where <size> is the user configurable size of the column
> data at which PostgreSQL switches from extended to external
> storage strategy ?

Actually, it just occurred to me that this ties into the recent
discussion of compression parameters
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php
(which hasn't gone further than discussion yet).  Perhaps we need
an additional parameter which is a maximum input size to attempt
compression at all.  IOW, the current force_input_size is not
only useless but exactly backwards ...

There was some discussion in that thread (or maybe the earlier
one on -patches) of exposing the lzcompress parameters directly
to users, perhaps as an extended form of the current SET STORAGE
command.  That won't happen for 8.3 but it might later.  In the
meantime, if the defaults included not attempting to compress
multi-megabyte values, I think it'd Just Work for cases like
yours.

            regards, tom lane

pgsql-general by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Writing most code in Stored Procedures
Next
From: Karsten Hilbert
Date:
Subject: Re: SUBSTRING performance for large BYTEA