From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Jameison Martin <jameisonb(at)yahoo(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <kgrittn(at)mail(dot)com>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] |
Date: | 2013-06-25 01:13:00 |
Message-ID: | CA+TgmoYEgRvoTnCeKm9fZKVZgRXFGpnFpRWwCjWsBHdmppS8gQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 24, 2013 at 4:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The point of what I was suggesting isn't to conserve storage, but to
> reduce downtime during a schema change. Remember that a rewriting ALTER
> TABLE locks everyone out of that table for a long time.
Sure, I understand. As Josh says, though, it'd still be potentially
quite surprising.
>> So, Tom, how's that pluggable storage format coming? :-)
>
> Well, actually, it's looking to me like heap_form_tuple will be
> underneath the API cut, because alternate storage managers will probably
> have other tuple storage formats --- column stores being the poster
> child here, but in any case the tuple header format is very unlikely
> to be universal.
I've had the same thought. Unfortunately, there are a lot of things -
like the TupleTableSlot abstraction - that are fairly deeply in bed
with the format used by our current heap AM; so we might be imposing a
performance overhead for anyone who uses some other representation.
Unless you have some idea how to avoid that?
> Which means that whether this patch gets applied to mainline is going
> to be moot for Salesforce's purposes; they will certainly want the
> equivalent logic in their storage code, because they've got tables with
> many hundreds of mostly-null columns, but whether heap_form_tuple acts
> this way or not won't affect them.
OK.
> So unless we consider that many-hundreds-of-columns is a design center
> for general purpose use of Postgres, we should be evaluating this patch
> strictly on its usefulness for more typical table widths. And my take
> on that is that (1) lots of columns isn't our design center (for the
> reasons you mentioned among others), and (2) the case for the patch
> looks pretty weak otherwise.
I guess I have yet to be convinced that it really hurts anything.
Your example seems fairly hypothetical and could easily be something
no one ever implements. I don't feel terribly strongly that we need
to take this patch, and I don't really care that much whether we do or
not; I'm just not really convinced there's any actual evidence that we
shouldn't. The standard isn't that it's got to make something really
important better; it's just got to make something better without
making anything more important worse.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2013-06-25 01:35:53 | Re: Possible bug in CASE evaluation |
Previous Message | Joe Conway | 2013-06-25 01:02:53 | Re: request a new feature in fuzzystrmatch |