Re: alternative compression algorithms?

On 30/04/15 00:44, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Apr 20, 2015 at 9:03 AM, Tomas Vondra
>> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>>> Sure, it's not an ultimate solution, but it might help a bit. I do have
>>> other ideas how to optimize this, but in the planner every milisecond
>>> counts. Looking at 'perf top' and seeing pglz_decompress() in top 3.
>
>> I suggested years ago that we should not compress data in
>> pg_statistic. Tom shot that down, but I don't understand why. It
>> seems to me that when we know data is extremely frequently accessed,
>> storing it uncompressed makes sense.
>
> I've not been following this thread, but I do not think your argument here
> holds any water. pg_statistic entries are generally fetched via the
> syscaches, and we fixed things years ago so that toasted tuple entries
> are detoasted before insertion in syscache. So I don't believe that
> preventing on-disk compression would make for any significant improvement,
> at least not after the first reference within a session.

AFAICS the syscache tuples are detoasted but not decompressed before
insertion to syscache (catcache calls toast_flatten_tuple which doesn't
do decompression) so the pglz_decompress is still called every time.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services