Dawid Kuroczko escribió:
> Currently the TOASTing code does its magic when whole tuple is
> larger than TOAST_TUPLE_TARGET which happens to be around 2KB.
>
> There are times though when one is willing to trade using (fast) CPU to
> reduce amount of (slow) I/O. A data warehousing types of workload
> most notably. Rarely used large columns which are likely to compress
> well but are not large enough to trigger inline compression.
I proposed in PGCon to have an option to select different compression
algorithms, for example gzip instead of our own PGLZ algorithm. In
testing I've found that for certain types of data, PGLZ compresses to
50% while gzip -8 compresses to 33%, albeit at a measurable CPU cost.
This is a tradeoff that some people might be interested in doing,
particularly on systems where the system is bottlenecked on I/O and you
have plenty of CPU to spare.
We are also considering bzip2 compression, which has the disadvantage
that the required library is not already linked in the backend, which
means we need ways to set that up too (loading shared libraries, etc).
This doesn't have a lot to do with what you are proposing, but I think
we need to come up with a reasonable user interface for all of this.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
