pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: David Steele <david@pgmasters.net>
Cc: Ildus Kurbangaliev <i.kurbangaliev@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [HACKERS] Custom compression methods (mac+lz4.h)
Date: Mon, 22 Mar 2021 11:47:59 -0400
Message-ID: <574197.1616428079@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoaG_p5VkYzAGQ0Ndo8PWPOm5Y55UoqBvkqSfoQmG=W1TA@mail.gmail.com>
References: <301730.1616276227@sss.pgh.pa.us>
	<20210320231957.GX11765@telsasoft.com>
	<309337.1616287493@sss.pgh.pa.us>
	<311370.1616290403@sss.pgh.pa.us>
	<CAFiTN-tN-fi=9VEatyiZyhW28yhhQCmn-egYzbdxBTLkOnVQvg@mail.gmail.com>
	<CAFiTN-t0w+Rc2U3S+y=7KWcLuOYNB5MfWeGdNa7+pg0UovVdcQ@mail.gmail.com>
	<414943.1616358751@sss.pgh.pa.us>
	<20210321204148.GB4203@telsasoft.com>
	<456616.1616360715@sss.pgh.pa.us>
	<504396.1616368310@sss.pgh.pa.us>
	<20210321234324.GC4203@telsasoft.com>
	<507597.1616370729@sss.pgh.pa.us>
	<CAFiTN-u1Y2i7TFfC+wZAEiQLHTYMSQafbRisYPqCaU6gQdnPcw@mail.gmail.com>
	<558766.1616424108@sss.pgh.pa.us>
	<CA+TgmoaG_p5VkYzAGQ0Ndo8PWPOm5Y55UoqBvkqSfoQmG=W1TA@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 22, 2021 at 10:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, I thought about that too, but do we want to assume that
>> VARRAWSIZE_4B_C is the correct way to get the decompressed size
>> for all compression methods?

> I think it's OK to assume this.

OK, cool.

>> (If so, I think it would be better style to have a less opaque macro
>> name for the purpose.)

> Complaining about the name of one particular TOAST-related macro name
> seems a bit like complaining about the greenhouse gasses emitted by
> one particular car.

Maybe, but that's not a reason to make it worse.  Anyway, my understanding
of that is that the really opaque names are *only* meant to be used in
this very stretch of postgres.h, ie they are just intermediate steps on
the way to the macros below them.  As an example, the only use of
VARDATA_1B_E() is in VARDATA_EXTERNAL().

> Anyway, this particular macro name was chosen, it seems, for symmetry
> with VARDATA_4B_C, but if you want to change it to something else, I'm
> OK with that, too.

After looking at postgres.h for a bit, I'm thinking that what these
should have been symmetric with is the considerably-less-terrible
names used for the corresponding VARATT_EXTERNAL cases.  Thus,
something like

s/VARRAWSIZE_4B_C/VARDATA_COMPRESSED_GET_RAWSIZE/
s/VARCOMPRESS_4B_C/VARDATA_COMPRESSED_GET_COMPRESSION/

Possibly the former names should survive and the latter become
wrappers around them, not sure.  But we shouldn't be using the "4B"
terminology anyplace except this part of postgres.h.

			regards, tom lane





view thread (21+ messages)  latest in thread

Message-ID: <574197.1616428079@sss.pgh.pa.us>
Permalink:  ../574197.1616428079@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/574197.1616428079@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, dilipbalaut@gmail.com, pryzby@telsasoft.com, andres@anarazel.de, tomas.vondra@2ndquadrant.com, a.korotkov@postgrespro.ru, david@pgmasters.net, i.kurbangaliev@gmail.com, 9erthalion6@gmail.com, x4mmm@yandex-team.ru, pgsql-hackers@lists.postgresql.org
  Subject: Re: [HACKERS] Custom compression methods (mac+lz4.h)
  In-Reply-To: <574197.1616428079@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox