Re: Text-any concatenation volatility acting as optimization barrier

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Text-any concatenation volatility acting as optimization barrier
Date: 2012-02-08 17:53:54
Message-ID: 28131.1328723634@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 02/08/2012 11:20 AM, Tom Lane wrote:
>> I am going to go ahead and commit the patch with the altered json
>> results, because IMO it is mere accident that these regression cases
>> were coming out with "nice" field labels anyway. When and if Andrew
>> gets the RowExpr cases fixed properly, that will show up as these
>> cases going back to nicer-looking output.

> I take it this is your way of making me hurry up with that work :-)

Well, right now the behavior is more consistent than it was before;
we would surely have gotten questions about it as it was. Whether
you find time to improve it or not isn't my concern at the moment.

BTW, the order of the items in the json output doesn't match the column
order of the sub-select, with or without the patch. This seems ... odd.
Is it intentional?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-02-08 17:58:51 Re: Progress on fast path sorting, btree index creation time
Previous Message Tom Lane 2012-02-08 17:48:20 Re: [PATCH] Enable min/max optimization for bool_and/bool_or/every