Re: [HACKERS] Custom compression methods - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: [HACKERS] Custom compression methods |
Date | |
Msg-id | CA+Tgmob3W8cnLgOQX+JQzeyGN3eKGmRrBkUY6WGfNyHa+t_qEw@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] Custom compression methods (Dilip Kumar <dilipbalaut@gmail.com>) |
Responses |
Re: [HACKERS] Custom compression methods
|
List | pgsql-hackers |
On Tue, Nov 24, 2020 at 7:11 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > About (4), one option is that we directly call the correct handler > function for the built-in type directly from > toast_(de)compress(_slice) functions but in that case, we are > duplicating the code, another option is that we call the > GetCompressionRoutine() a common function and in that, for the > built-in type, we can directly call the corresponding handler function > and get the routine. The only thing is to avoid duplicating in > decompression routine we need to convert CompressionId to Oid before > calling GetCompressionRoutine(), but now we can avoid sys cache lookup > for the built-in type. Suppose that we have a variable lz4_methods (like heapam_methods) that is always defined, whether or not lz4 support is present. It's defined like this: const CompressionAmRoutine lz4_compress_methods = { .datum_compress = lz4_datum_compress, .datum_decompress = lz4_datum_decompress, .datum_decompress_slice = lz4_datum_decompress_slice }; (It would be good, I think, to actually name things something like this - in particular why would we have TableAmRoutine and IndexAmRoutine but not include "Am" in the one for compression? In general I think tableam is a good pattern to adhere to and we should try to make this patch hew closely to it.) Then those functions are contingent on #ifdef HAVE_LIBLZ4: they either do their thing, or complain that lz4 compression is not supported. Then in this function you can just say, well, if we have the 01 bit pattern, handler = &lz4_compress_methods and proceed from there. BTW, I think the "not supported" message should probably use the 'by this build' language we use in some places i.e. [rhaas pgsql]$ git grep errmsg.*'this build' | grep -vF .po: contrib/pg_prewarm/pg_prewarm.c: errmsg("prefetch is not supported by this build"))); src/backend/libpq/be-secure-openssl.c: (errmsg("\"%s\" setting \"%s\" not supported by this build", src/backend/libpq/be-secure-openssl.c: (errmsg("\"%s\" setting \"%s\" not supported by this build", src/backend/libpq/hba.c: errmsg("local connections are not supported by this build"), src/backend/libpq/hba.c: errmsg("hostssl record cannot match because SSL is not supported by this build"), src/backend/libpq/hba.c: errmsg("hostgssenc record cannot match because GSSAPI is not supported by this build"), src/backend/libpq/hba.c: errmsg("invalid authentication method \"%s\": not supported by this build", src/backend/utils/adt/pg_locale.c: errmsg("ICU is not supported in this build"), \ src/backend/utils/misc/guc.c: GUC_check_errmsg("Bonjour is not supported by this build"); src/backend/utils/misc/guc.c: GUC_check_errmsg("SSL is not supported by this build"); -- Robert Haas EDB: http://www.enterprisedb.com
pgsql-hackers by date: