Date: Thu, 23 Apr 2015 15:10:41 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: "Joshua D. Drake" <jd@commandprompt.com>
Cc: Jim Nasby <Jim.Nasby@BlueTreble.com>,
 Andres Freund <andres@anarazel.de>, hlinnaka@iki.fi,
 Petr Jelinek <petr@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
 Bruce Momjian <bruce@momjian.us>,
 Sawada Masahiko <sawada.mshk@gmail.com>, Greg Stark <stark@mit.edu>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Jeff Janes <jeff.janes@gmail.com>
Subject: Re: Reducing tuple overhead
Message-ID: <20150423181041.GL4369@alvh.no-ip.org>
References: <20150423162429.GG3055@alap3.anarazel.de>
 <553920F0.8030206@BlueTreble.com>
 <5539253D.8000506@commandprompt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5539253D.8000506@commandprompt.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Thanks for posting this.

Joshua D. Drake wrote:

> First of all I should note that I discussed the approach mentioned above to
> pgsql-hackers and got a very interesting comment from Tom Lane that adding
> sorting info to Var and TargetEntry nodes was not a very good idea because
> it'd break stored rules whenever a table column changed. So I went back and
> studied that code and noticed that it was really the change in
> RangeTableEntry that's doing the good magic; those other changes are
> fortunately not necessary. (Though there were a necessary vehicle for me to
> understand how the other stuff works.)

So in the logical columns thread I was saying that this change of eref
didn't work either; it seems that most of the time (if not always) the
list should continue to be in attnum order, and the
logical-ordering-info data should be obtained from the tuple descriptor
and whatever needs to be sorted should be sorted afterwards, i.e. in
setrefs.c, using data previously stored in RelOptInfo.  I tried doing
that and ran into some other mess elsewhere.

> I've been continuing to study the backend code looking for uses of attribute
> lists that assume a single ordering. As I get more into it, more complex
> cases appear. The number of cases is fortunately bounded, though.

<he hopes, and eventually gives up>

> However, some other places are not like that. I have "fixed" SQL functions
> two times now, and I just found out that the second fix (which I believed to
> be "mostly correct") was to be the final one, but I found out just now that
> it's not, and the proper fix is going to require something a bit more
> low-level (namely, a projection step that reorders columns correctly after
> the fact). Fortunately, I believe that this extra projection step is going
> to fix a lot of other cases too, which I originally had no idea how to
> attack. Moreover, understanding that bit means I also figured out what Tom
> Lane meant on the second half of his response to my original pgsql-hackers
> comment. So I think we're good on that front.

I had forgotten my intention to rework things using projection.

In any case, I have posted a lot of patches now which others could
study, if there's interest.  I would sure like to see this split, and
there are multiple benefits such as reduction of padding space.  I'm
sure there's a nonempty set of guys brighter than me that could figure
it out in not that much time.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers