From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Regina Obe <r(at)pcorp(dot)us> |
Subject: | Re: Compressed TOAST Slicing |
Date: | 2019-03-13 10:09:35 |
Message-ID: | e06775ac-1baf-9fb1-6107-a69b6c9a6438@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/13/19 3:19 AM, Michael Paquier wrote:
> On Tue, Mar 12, 2019 at 07:01:17PM -0700, Andres Freund wrote:
>> I don't think this is even close to popular enough to incur the
>> maybe of a separate function / more complicated interface. By this
>> logic we can change basically no APIs anymore.
>
> Well, if folks here think that it is not worth worrying about, I won't
> cry on that either. If only the original API is kept, could it just
> be possible to make it extensible with some bits16 flags then? Adding
> only a boolean is not really appealing.
In my experience "extensible" APIs with bitmasks are terrible - it's a
PITA to both use them and maintain stuff that calls them. That is not to
say there is no use for that design pattern, or that I like API breaks.
But I very much prefer when an API change breaks things, alerting me of
places that may require attention.
And I'm with Andres here about the complexity being rather unwarranted
here - I don't think we've changed pglz API in years (if ever), so what
is the chance we'd actually benefit from the extensibility soon?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-03-13 10:10:21 | Re: Offline enabling/disabling of data checksums |
Previous Message | Georgios Kokolatos | 2019-03-13 09:56:40 | Re: CPU costs of random_zipfian in pgbench |