Re: WIP: Upper planner pathification

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: WIP: Upper planner pathification
Date: 2016-03-01 14:09:09
Message-ID: 56D5A285.4060808@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/28/16 4:02 PM, Andres Freund wrote:
>> So, where to go from here? I'm acutely aware that we're hard up against
>> >the final 9.6 commitfest, and that we discourage major patches arriving
>> >so late in a devel cycle. But I simply couldn't get this done any faster.
>> >I don't really want to hold it over for the 9.7 devel cycle. It's been
>> >enough trouble maintaining this patch in the face of conflicting commits
>> >over the last year or so (it's probably still got bugs related to parallel
>> >query...), and there definitely are conflicting patches in the upcoming
>> >'fest. And the lack of this infrastructure is blocking progress on FDWs
>> >and some other things.
>> >
>> >So I'd really like to get this into 9.6. I'm happy to put it into the
>> >March commitfest if someone will volunteer to review it.
> Hard. This is likely to cause/trigger a number of bugs, and we don't
> have much time to let this mature. It's a change that we're unlikely to
> be able to back-out if we discover that it wasn't the right thing to
> integrate shortly before the release. On the other hand, this is a
> major architectural step forward; one that unblocks a number of nice
> features. There's also an argument to be made that integrating this now
> is beneficial, because it'll cause less churn for patches being
> developed while 9.6 is stabilizing.

Perhaps the best way to handle this would be to commit it to a branch
sooner rather than later. If things work out, that branch can become the
official beta. If not, in can become the basis for 9.7.

If nothing else it means that Tom isn't the only one stuck trying to
maintain this. Even if the branch is nothing but a means to generating a
patch for 9.7, having it in place makes it a lot easier for other
developers that need to to code against it.

While I'm promoting heresy... I imagine that this patch doesn't require
a catversion bump. Perhaps it would be worth doing a short-cycle major
release just to get this in. That might sound insane but since one of
the biggest obstacles to upgrading remains dealing with the on-disk
format, I don't think users would freak out about it.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-03-01 14:15:06 Sort returns more rows than seq scan?
Previous Message salvador fandino 2016-03-01 14:08:14 Re: TAP / recovery-test fs-level backups, psql enhancements etc