Re: [HACKERS] Custom compression methods - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Custom compression methods
Date
Msg-id CA+TgmoZitfcQJu+UKCjj9S_2adVCHJNb7EarBzn_qUF_nRxJZw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Custom compression methods  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Feb 5, 2021 at 11:07 AM Robert Haas <robertmhaas@gmail.com> wrote:
> Personally, my preference is to just update the test outputs. It's not
> important whether many people look closely to verify the differences;
> we just need to look them over on a one-time basis to see if they seem
> OK. After that it's 0 effort, vs. having to maintain HIDE_COMPRESSAM
> forever.

Oh, I guess you're thinking about the case where someone wants to run
the tests with a different default. That might be a good reason to
have this. But then those changes should go in 0002.

Regarding 0002, I'm not feeling very excited about having every call
to TupleDescInitEntry() do an extra syscache lookup. It's going to be
the same lookup every time forever to get the same value every time
forever. Now maybe that function can never get hot enough for it to
matter, but can't we find a way to be smarter about this? Like,
suppose we cache the OID in a global variable the first time we look
it up, and then use CacheRegisterSyscacheCallback() to have it zeroed
out if pg_am is updated?

Taking that idea a bit further, suppose you get rid of all the places
where you do get_compression_am_oid(default_toast_compression, false)
and change them to get_default_compression_am_oid(), which is defined
thus:

static Oid
get_default_compression_am_oid(void)
{
    if (unlikely(!OidIsValid(cached_default_compression_oid))
      // figure it out;
    return cached_default_compression_oid;
}

Also, how about removing the debugging leftovers from syscache.c?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Custom compression methods
Next
From: Robert Haas
Date:
Subject: Re: making update/delete of inheritance trees scale better