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

From Alvaro Herrera
Subject Re: [HACKERS] Custom compression methods
Date
Msg-id 20201124192031.GA22772@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] Custom compression methods  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Custom compression methods  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On 2020-Nov-24, Tom Lane wrote:

> Robert Haas <robertmhaas@gmail.com> writes:

> > Oh, I thought it had been suggested in previous discussions that these
> > should be treated as access methods rather than inventing a whole new
> > concept just for this, and it seemed like a good idea to me. I guess I
> > missed the fact that the patch wasn't doing it that way. Hmm.
> 
> FWIW, I kind of agree with Robert's take on this.  Heap and index AMs
> are pretty fundamentally different animals, yet we don't have a problem
> sticking them in the same catalog.  I think anything that is related to
> storage access could reasonably go into that catalog, rather than
> inventing a new one.

Right -- Something like amname=lz4, amhandler=lz4handler, amtype=c.
The core code must of course know how to instantiate an AM of type
'c' and what to use it for.

https://postgr.es/m/20171213151818.75a20259@postgrespro.ru



pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Next
From: Tom Lane
Date:
Subject: Re: enable_incremental_sort changes query behavior