Обсуждение: feature freeze and beta schedule

The schedule
<https://wiki.postgresql.org/wiki/PgCon_2014_Developer_Meeting#9.5_Schedule>
calls for beta in June.  In light of that, the core team has agreed to
call for
   feature freeze on May 15

That means that all patches that add or change features should be
committed by then.

If you have spare cycles, there are a number of relevant patches still
open in the commit fest.

On Thu, Apr 30, 2015 at 8:39 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> The schedule
> <https://wiki.postgresql.org/wiki/PgCon_2014_Developer_Meeting#9.5_Schedule>
> calls for beta in June.  In light of that, the core team has agreed to
> call for
>
>     feature freeze on May 15
>
> That means that all patches that add or change features should be
> committed by then.
>
> If you have spare cycles, there are a number of relevant patches still
> open in the commit fest.

What do we think this means in terms of the schedule for the final release?

Looking at the history:

9.4beta1 was stamped on May 11th; 9.4 was released December 18th.
9.3beta1 was stamped on May 6th; 9.3 was released September 9th.
9.2beta1 was stamped on May 10th; 9.2 was released September 10th.
9.1beta1 was stamped on April 27th; 9.1 was released September 12th.
9.0beta1 was stamped on April 30th; 9.0 was released September 20th.

So generally we have stamped in late April or early May and released
in September, but last year we didn't release until December.  I
assume that if we stamp beta1 in June instead of May, that's going to
somewhat delay the final release as well, but I'm not sure how much.

Looking at the CF page, we're doing better than I thought: we're down
from 113 patches to just 50.  That's good, but it's still an awful lot
to handle in the next two weeks.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 4/30/15 12:01 PM, Robert Haas wrote:
> So generally we have stamped in late April or early May and released
> in September, but last year we didn't release until December.  I
> assume that if we stamp beta1 in June instead of May, that's going to
> somewhat delay the final release as well, but I'm not sure how much.

The idea when that schedule was cobbled together in the dying minutes of
the last developer meeting ;-) was to have a shorter beta and still
shoot for a September release.

On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 4/30/15 12:01 PM, Robert Haas wrote:
>> So generally we have stamped in late April or early May and released
>> in September, but last year we didn't release until December.  I
>> assume that if we stamp beta1 in June instead of May, that's going to
>> somewhat delay the final release as well, but I'm not sure how much.
>
> The idea when that schedule was cobbled together in the dying minutes of
> the last developer meeting ;-) was to have a shorter beta and still
> shoot for a September release.

I think that could be doable if we can keep focus, but that's easier
said than done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, May 1, 2015 at 1:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On 4/30/15 12:01 PM, Robert Haas wrote:
>>> So generally we have stamped in late April or early May and released
>>> in September, but last year we didn't release until December.  I
>>> assume that if we stamp beta1 in June instead of May, that's going to
>>> somewhat delay the final release as well, but I'm not sure how much.
>>
>> The idea when that schedule was cobbled together in the dying minutes of
>> the last developer meeting ;-) was to have a shorter beta and still
>> shoot for a September release.
>
> I think that could be doable if we can keep focus, but that's easier
> said than done.

Just to make people aware here that I am not slacking: I am going to
be out of town for a couple of weeks more or less until the end of May
with limited access to computer so I am not sure I will be able to
help much.
Regards,
-- 
Michael

On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
> If you have spare cycles, there are a number of relevant patches still
> open in the commit fest.

I was wondering what the actual state of the commitfest is. I'm thus
going through all the open items. Here's my thoughts:


* fsync $PGDATA recursively at startup Bugfix, i.e. not really tied to CF

* EvalPlanQual behaves oddly for FDW queries involving system columns Tom wants to take care of it next week. => Keep
in'ready for committer'
 

* Do not vacuum pgbench tables if they do not exist when pgbench -f given Robert was recently sending an iteration of a
patch,so I think this is being taken care of. => Keep in 'ready for committer'
 

* Multivariate statistics This is not intended to be committed this CF. => I'd like to mark this as returned with
(little)feedback.
 

* fastbloat Not too big, I think it should be easy to commit this. => Keep in 'ready for committer'

* Avoiding plan disasters with LIMIT I'm not enthused by the approach, it's disabled by default though. So it might not
betoo bad to just do it. Would probably have been a good idea to discuss the patch in a separate thread. => ?
 

* Turning off HOT for larger SQL queries Seems to have degenerated into a discussion of not really related things. I
personallywould vote for committing something close to what Simon proposed last *directly at the beginning* of the next
cycle.=> Move?
 

* BRIN inclusion operator class This seems to be a mishmash of bugfix and feature. The bugfixes should be applied
pdq...=> ?
 
* Async execution of postgres_fdw.
 Later iterations of the patch haven't gotten much review yet. The original version of the patch is just from
2014-12-15.=> Should imo be moved to the next CF
 

* PageRepairFragmentation optimization Hm. Heikki hasn't replied recently. It's a committer's patch though, so it
probablydoesn't matter that much. => Move?
 

* Abbreviated key support for Datum sorts Unfortunately the discussion about potential performance regression has been
largelysidestepped by bickering over minutiae. => ?
 

* Unique Joins This seems to require more work and came in pretty late => Returned with feedback.

* INNER JOIN removals Seem far to controversial to consider comitting in 9.5. => Returned (or even rejected :()

* Aggregate State Combine Support I think we pretty clearly need something roughly like this. It seems equally clear
thatthis isn't going to happen in 9.5 => Returned with feedback
 

* Allow "snapshot too old" error, to prevent bloat
http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.comtalked about
anew version that afaics never materialized => Returned with feedback
 

* KNN-GiST with recheck Unfortunately the last version hasn't gotten feedback. The topic is somewhat old, so I'd be
uglyto not do somethign about it this CF. I can't judge the state of the patch right now. => ?
 

* GIN fillfactor Seems like a simple enough idea. => I guess somebody should review and commit it?

* Manipulating complex types as non-contiguous structures in-memory Pretty large for this state and being proposed
late.On the other hand it's Tom. Looks like it could use some review tho. => ?
 

* Optimization for updating foreign tables in Postgres FDW Hm. The last, significantly redone, iteration doesn't seem
tohave gotten much code level review. => ?
 

* iteration over record in plpgsql To me this still seems to be in the in the design phase. => Return?

* Sequence Access Method There's been some back and forth between Petr and Heikki on this lately. => Maybe there's
stilla chance for 9.5?
 

* archive_mode=shared/always Hasn't really gotten code level review yet. Heikki?

* Sending WAL receiver feedback regularly even if the receiver is under heavy load Imo more of a bugfix than a feature.
I.e.doesn't really concern the CF scheduling.
 

* Auditing extension I'm unclear on the status here. Abhijit said he'll have a look.

* Parallel Seq scan In my opinion the topic has progressed greatly. But at the same time it doesn't seem like it's in a
statewe should consider for 9.5. => Return?
 

* ctidscan as an example of custom-scan Hasn't really gotten sufficient review. => Move

* logical column ordering (WIP) This pretty clearly isn't 9.5 material. => Return

* parallel mode/contexts The largest part of this has just been committed. There's more contentious/complicated bits
aroundlocking left. I have a hard time believing we have the cycles to resolve those for 9.5. It'd be neat if we could,
butI think "older" stuff has a bit of precedence.
 

* Support ORDER BY in CREATE FUNCTION for Set Returning Functions Uhm. I think the outcome of the discussion so far
wasn'treally favorable to the idea s proposed. => Rejected
 

* RLS: row-level security, more review More of a placeholder item. There seem to various open items.

* Cube extension kNN support Waiting on author for a few weeks, and submitted late. => Returned with feedback

* compress method for spgist Hm. Changes spgist's API. Hasn't gotten review in the redone version. But it's also not
thatlarge? => Move?
 

* mogrify and indent for jsonb Committer's patch marked as ready for commit. => Should get committed ;)

* assessing parallel-safety Unclear. The patch isn't particularly huge, but I'm not sure the design is full finished
yet.It also came in somewhat late. => Unclear.
 

* Join pushdown support for foreign tables Hasn't gotten particularly much review yet. And it doesn't look entirely
readyto me on a very quick scan. But I don't know that much about the area. => Move?
 

* Deparsing utility commands IIUc Alvaro intends to commit a minimal version soon.

* Grouping Sets Tom intends to take a peek next week.

* INSERT ... ON CONFLICT {UPDATE | IGNORE} Heikki, Peter and I have spent a fair amount of time on this. I believe we
cancommit it early next week.
 

* TABLESAMPLE clause Doesn't seem very far from being done. Some questions about including (or not) DDL and contrib
modulesseem to remain.
 

* REINDEX xxx VERBOSE Looks simple enough to commit soon.

* regrole and regnamespace Looks simple enough to commit soon.

* pg_basebackup vs. Windows and tablespaces Should be committed.

* Additional role attributes I agree with Robert's point in
http://archives.postgresql.org/message-id/CA%2BTgmobH4tdccajn7VmPT-1RqBdzLYcAz5jUz4bJ%3Drkqs_gADA%40mail.gmail.comand
thusthink that this patch isn't ready for 9.5.
 

* catalog view to pg_hba.conf file Greg is marked as a comitter here.

* pg_file_settings view: To know detail of config files via SQL Seems to be ready.

* Add pg_settings.pending_restart column Looks like it coudl quickly be committed.


Greetings,

Andres Freund

On Fri, May 1, 2015 at 9:37 AM, Andres Freund <andres@anarazel.de> wrote:
> * Abbreviated key support for Datum sorts
>   Unfortunately the discussion about potential performance regression
>   has been largely sidestepped by bickering over minutiae.
>   => ?

There really is no discussion about performance regressions, because
there doesn't have to be. It's a straightfroward case of making what
already works for the heap tuple and B-Tree tuple sort cases work for
the Datum case. The costs and the benefits are the same.

It was marked "ready for committer" some time ago.
-- 
Peter Geoghegan

On 2015-05-01 13:05:19 -0400, Simon Riggs wrote:
> On 1 May 2015 at 12:37, Andres Freund <andres@anarazel.de> wrote:
> > * fastbloat
> >   Not too big, I think it should be easy to commit this.
> >   => Keep in 'ready for committer'
> >
> 
> Will commit soon

Cool.


> > * Allow "snapshot too old" error, to prevent bloat
> >
> > http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.com
> >   talked about a new version that afaics never materialized
> >   => Returned with feedback

> Would like to review this

Kevin hasn't posted that new version yet, has he?
> * Sending WAL receiver feedback regularly even if the receiver is under
> 
> >   heavy load
> >   Imo more of a bugfix than a feature. I.e. doesn't really concern the
> >   CF scheduling.
> >
> 
> Agreed, bug fix. Will do if Fujii doesn't
> 
> 
> > * Auditing extension
> >   I'm unclear on the status here. Abhijit said he'll have a look.
> >
> 
> Maybe me, but running out of time
> 
> 
> > * TABLESAMPLE clause
> >   Doesn't seem very far from being done. Some questions about including
> >   (or not) DDL and contrib modules seem to remain.
> >
> 
> Will commit this soon

Cool.

Thanks for the update,

Andres

On 2015-05-01 09:49:50 -0700, Peter Geoghegan wrote:
> On Fri, May 1, 2015 at 9:37 AM, Andres Freund <andres@anarazel.de> wrote:
> > * Abbreviated key support for Datum sorts
> >   Unfortunately the discussion about potential performance regression
> >   has been largely sidestepped by bickering over minutiae.
> >   => ?
> 
> There really is no discussion about performance regressions, because
> there doesn't have to be. It's a straightfroward case of making what
> already works for the heap tuple and B-Tree tuple sort cases work for
> the Datum case. The costs and the benefits are the same.
> 
> It was marked "ready for committer" some time ago.

Why is
http://www.postgresql.org/message-id/54E79F9C.4090208@2ndquadrant.com
not worth a discussion?  I don't see your response in
http://www.postgresql.org/message-id/CAM3SWZTY9fmrn9q8uMsqn9bnedtjk68FKitoMhHSXY2kOyv9xA@mail.gmail.com
really debating why it's definitely worth the cost.  I'm not saying it's
*not* worth it, just that it has to be considered.

Greetings,

Andres Freund

Andres,

* Andres Freund (andres@anarazel.de) wrote:
> On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
> > If you have spare cycles, there are a number of relevant patches still
> > open in the commit fest.
>
> I was wondering what the actual state of the commitfest is. I'm thus
> going through all the open items. Here's my thoughts:

Thanks!

> * fsync $PGDATA recursively at startup
>   Bugfix, i.e. not really tied to CF

We really need to segregate the two..  By that what I mean is this: I
want an "always-open" "bugfix" CF, which allows us to keep track of
bugfix patches.  Having something about "applies to versions X, Y, Z"
would be nice too...

/me prods Magnus

> * Async execution of postgres_fdw.
>
>   Later iterations of the patch haven't gotten much review yet. The
>   original version of the patch is just from 2014-12-15.
>   => Should imo be moved to the next CF

I'd love to see this happen, but I haven't got cycles to spend on it
between now and feature freeze. :/

> * INNER JOIN removals
>   Seem far to controversial to consider comitting in 9.5.
>   => Returned (or even rejected :()

I'd really like to see this too, but I agree it's not something for 9.5
at this point.

> * Aggregate State Combine Support
>   I think we pretty clearly need something roughly like this. It seems
>   equally clear that this isn't going to happen in 9.5
>   => Returned with feedback

Agreed.

> * Allow "snapshot too old" error, to prevent bloat
>   http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.com
>   talked about a new version that afaics never materialized
>   => Returned with feedback

As mentioned earlier, this is a committer's patch and if Kevin shows up
with a new patch based on that discussion which others can live with,
then I'm for having the capability over not.  As such, not sure if RFW
is the right state for it to be in at this point.

> * Sending WAL receiver feedback regularly even if the receiver is under
>   heavy load
>   Imo more of a bugfix than a feature. I.e. doesn't really concern the
>   CF scheduling.

Another one for that "bugfix" CF...

> * Auditing extension
>   I'm unclear on the status here. Abhijit said he'll have a look.

It was recently set to ready-for-committer by Sawada (he and David have
been going back and forth with testing, fixing, etc).  Fujii took a look
and had a few comments which David responded to.  As is probably
obvious, it's certainly something that I'd like to see happen as it's an
oft-requested feature.  Certainly would be great if Abhijit could look
at it.

> * Parallel Seq scan
>   In my opinion the topic has progressed greatly. But at the same time
>   it doesn't seem like it's in a state we should consider for 9.5.
>   => Return?

I'd certainly love to see it happen but I've not been following the
recent discussion and so I'm not really sure if it's ready or not.

> * RLS: row-level security, more review
>   More of a placeholder item. There seem to various open items.

I've addressed a few of them lately..  If there are more then I've lost
track of what they are and would certainly welcome folks reminding me.
In particular, the issue from Craig about the misleading error has been
addressed and I believe we've worked out the RLS+INSERT ... ON CONFLICT
questions.

> * Deparsing utility commands
>   IIUc Alvaro intends to commit a minimal version soon.

+1

> * INSERT ... ON CONFLICT {UPDATE | IGNORE}
>   Heikki, Peter and I have spent a fair amount of time on this. I believe
>   we can commit it early next week.

Yay!

> * Additional role attributes
>   I agree with Robert's point in
>   http://archives.postgresql.org/message-id/CA%2BTgmobH4tdccajn7VmPT-1RqBdzLYcAz5jUz4bJ%3Drkqs_gADA%40mail.gmail.com
>   and thus think that this patch isn't ready for 9.5.

I agree it needs more discussion and am planning on posting both a much
simpler patch (which removes the complicated changes to pg_dump) and
putting it on the new thread to get some real discussion about it.
Robert's point that these changes need discussion is certainly spot on
and that may lead to it not getting into 9.5, but I'm not quite ready to
punt on it yet given that we've been working on it for going on 6(?)
months now.

> * catalog view to pg_hba.conf file
>   Greg is marked as a comitter here.

I'm happy to help with this also.

> * pg_file_settings view: To know detail of config files via SQL
>   Seems to be ready.

I'm looking at this too.

> * Add pg_settings.pending_restart column
>   Looks like it coudl quickly be committed.

No objection here.
Thanks!
    Stephen

----- Original Message -----
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-hackers <pgsql-hackers@postgresql.org>
Sent: Friday, May 1, 2015 12:16 PM
Subject: Re: [HACKERS] feature freeze and beta schedule

Andres,

* Andres Freund (andres@anarazel.de) wrote:
> On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
> > If you have spare cycles, there are a number of relevant patches still
> > open in the commit fest.
> 
> I was wondering what the actual state of the commitfest is. I'm thus
> going through all the open items. Here's my thoughts:

Thanks!

> * fsync $PGDATA recursively at startup
>   Bugfix, i.e. not really tied to CF

We really need to segregate the two..  By that what I mean is this: I
want an "always-open" "bugfix" CF, which allows us to keep track of
bugfix patches.  Having something about "applies to versions X, Y, Z"
would be nice too...

/me prods Magnus

> * Async execution of postgres_fdw.
> 
>   Later iterations of the patch haven't gotten much review yet. The
>   original version of the patch is just from 2014-12-15.
>   => Should imo be moved to the next CF

I'd love to see this happen, but I haven't got cycles to spend on it
between now and feature freeze. :/

> * INNER JOIN removals
>   Seem far to controversial to consider comitting in 9.5.
>   => Returned (or even rejected :()

I'd really like to see this too, but I agree it's not something for 9.5
at this point.

> * Aggregate State Combine Support
>   I think we pretty clearly need something roughly like this. It seems
>   equally clear that this isn't going to happen in 9.5
>   => Returned with feedback

Agreed.

> * Allow "snapshot too old" error, to prevent bloat
>  http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.com
>   talked about a new version that afaics never materialized
>   => Returned with feedback

As mentioned earlier, this is a committer's patch and if Kevin shows up
with a new patch based on that discussion which others can live with,
then I'm for having the capability over not.  As such, not sure if RFW
is the right state for it to be in at this point.

> * Sending WAL receiver feedback regularly even if the receiver is under
>   heavy load
>   Imo more of a bugfix than a feature. I.e. doesn't really concern the
>   CF scheduling.

Another one for that "bugfix" CF...

> * Auditing extension
>   I'm unclear on the status here. Abhijit said he'll have a look.

It was recently set to ready-for-committer by Sawada (he and David have
been going back and forth with testing, fixing, etc).  Fujii took a look
and had a few comments which David responded to.  As is probably
obvious, it's certainly something that I'd like to see happen as it's an
oft-requested feature.  Certainly would be great if Abhijit could look
at it.

> * Parallel Seq scan
>   In my opinion the topic has progressed greatly. But at the same time
>   it doesn't seem like it's in a state we should consider for 9.5.
>   => Return?

I'd certainly love to see it happen but I've not been following the
recent discussion and so I'm not really sure if it's ready or not.

> * RLS: row-level security, more review
>   More of a placeholder item. There seem to various open items.

I've addressed a few of them lately..  If there are more then I've lost
track of what they are and would certainly welcome folks reminding me.
In particular, the issue from Craig about the misleading error has been
addressed and I believe we've worked out the RLS+INSERT ... ON CONFLICT
questions.

> * Deparsing utility commands
>   IIUc Alvaro intends to commit a minimal version soon.

+1

> * INSERT ... ON CONFLICT {UPDATE | IGNORE}
>   Heikki, Peter and I have spent a fair amount of time on this. I believe
>   we can commit it early next week.

Yay!

> * Additional role attributes
>   I agree with Robert's point in
>  http://archives.postgresql.org/message-id/CA%2BTgmobH4tdccajn7VmPT-1RqBdzLYcAz5jUz4bJ%3Drkqs_gADA%40mail.gmail.com
>   and thus think that this patch isn't ready for 9.5.

I agree it needs more discussion and am planning on posting both a much
simpler patch (which removes the complicated changes to pg_dump) and
putting it on the new thread to get some real discussion about it.
Robert's point that these changes need discussion is certainly spot on
and that may lead to it not getting into 9.5, but I'm not quite ready to
punt on it yet given that we've been working on it for going on 6(?)
months now.

> * catalog view to pg_hba.conf file
>   Greg is marked as a comitter here.

I'm happy to help with this also.

> * pg_file_settings view: To know detail of config files via SQL
>   Seems to be ready.

I'm looking at this too.


> * Add pg_settings.pending_restart column
>   Looks like it coudl quickly be committed.

No objection here.
   Thanks!

       Stephen 

Stephen Frost <sfrost@snowman.net> wrote:
> Andres Freund (andres@anarazel.de) wrote:

>> * Allow "snapshot too old" error, to prevent bloat
>> http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.com
>>  talked about a new version that afaics never materialized
>>  => Returned with feedback
>
> As mentioned earlier, this is a committer's patch and if Kevin
> shows up with a new patch based on that discussion which others
> can live with, then I'm for having the capability over not.  As
> such, not sure if RFW is the right state for it to be in at this
> point.

Unfortunately, other emergencies have cut into my time for
finishing this for 9.5, and it seems more appropriate for a "start
of release cycle" patch than a "just before beta" patch; so look
for that in the first CF for the next release.  (Of course, if
someone wants to run with it and wants to argue for 9.5, I'll do
what I can to ensure it is solid.)

The current status, as I see it, are that there are two things that
need to be done:

(1)  The GUC needs to be changed from number of transactions to
time-based.  This is partly done, and could probably be finished in
a couple full-time days.

(2)  Every index AM needs to insert a TestForOldSnapshot() call
after each BufferGetPage() call which is used for a search or scan.
(Those used to position for inserts or other internal purposes
don't need this treatment.)  The btree AM is already done, but no
other AM has been started.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 01/05/15 18:37, Andres Freund wrote:
> I was wondering what the actual state of the commitfest is. I'm thus
> going through all the open items. Here's my thoughts:
>

Cool.

> * Sequence Access Method
>    There's been some back and forth between Petr and Heikki on this
>    lately.
>    => Maybe there's still a chance for 9.5?
>

I think it depends mainly on if we are happy with the proposed API or 
not (especially the storage API). AFAIK all the comments Heikki had were 
addressed, but public API like this can always use more eyes...

>
> * mogrify and indent for jsonb
>    Committer's patch marked as ready for commit.
>    => Should get committed ;)
>

It's only partly a committer's patch but I agree that it's now in a 
state where it should be committed.

>
> * Deparsing utility commands
>    IIUc Alvaro intends to commit a minimal version soon.
>

Amit had few comments that need to be addressed but other than that the 
infrastructure part is definitely committable. The current approach is 
really good.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services

>>>>> "Andres" == Andres Freund <andres@anarazel.de> writes:
Andres> * Abbreviated key support for Datum sortsAndres>   Unfortunately the discussion about potential
performanceAndres>  regression has been largely sidestepped by bickering overAndres>   minutiae.Andres>   => ?
 

There isn't a "potential performance regression" that is in any respect
different from the already-committed changes for non-Datum sorts.

Also as I've pointed out, it's not even clear that there is a regression
at all, since I've already shown that changes of several percent in
timings of sort operations can be caused by irrelevant noise factors.
To actually show a performance regression of less than 10% or so would
require, at a minimum, showing two different timings using the same data
and the same binary, though even that is subject to noise; to really
prove it you'd have to show a statistically significant difference
between sets of binaries with random padding sizes (see the graph I
posted on this point).

-- 
Andrew (irc:RhodiumToad)

On Fri, May 1, 2015 at 5:27 PM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
> Also as I've pointed out, it's not even clear that there is a regression
> at all, since I've already shown that changes of several percent in
> timings of sort operations can be caused by irrelevant noise factors.
> To actually show a performance regression of less than 10% or so would
> require, at a minimum, showing two different timings using the same data
> and the same binary, though even that is subject to noise; to really
> prove it you'd have to show a statistically significant difference
> between sets of binaries with random padding sizes (see the graph I
> posted on this point).

I think the issue is somewhat confused by the fact that there was
performance investigation work done on the thread, and a regression
was investigated (a regression that has since been fixed). This was a
problem that had nothing in particular to do with the Datum tuplesort
abbreviation patch, though.

-- 
Peter Geoghegan

2015-05-02 1:37 GMT+09:00 Andres Freund <andres@anarazel.de>:
> * ctidscan as an example of custom-scan
>   Hasn't really gotten sufficient review.
>   => Move
>
I have to agree.

> * Join pushdown support for foreign tables
>   Hasn't gotten particularly much review yet. And it doesn't look
>   entirely ready to me on a very quick scan. But I don't know that much
>   about the area.
>   => Move?
>
I think its overall design had been discussed and people reached
consensus. Even though some documentation / comments works
are required, it is not a fundamental design change isn't it?
I expect the join-pushdown of postgres_fdw will reach the commitable
state within two weeks.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

On Fri, May 1, 2015 at 1:16 PM, Stephen Frost <sfrost@snowman.net> wrote:
> We really need to segregate the two..  By that what I mean is this: I
> want an "always-open" "bugfix" CF, which allows us to keep track of
> bugfix patches.  Having something about "applies to versions X, Y, Z"
> would be nice too...
>
> /me prods Magnus

I don't really see that as a step forward.  Right now there's one
place to look at for patches that somebody wants me (or someone) to
pay attention to, and, when time permits, I look at it.  Dividing that
up into two places is not going to make me look at them more
frequently.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2015-05-01 18:37:23 +0200, Andres Freund wrote:
> * Multivariate statistics
>   This is not intended to be committed this CF.
>   => I'd like to mark this as returned with (little) feedback.
>
> * Avoiding plan disasters with LIMIT
>   I'm not enthused by the approach, it's disabled by default though. So
>   it might not be too bad to just do it. Would probably have been a good
>   idea to discuss the patch in a separate thread.
>   => ?
>
> * Turning off HOT for larger SQL queries
>   Seems to have degenerated into a discussion of not really related
>   things. I personally would vote for committing something close to what
>   Simon proposed last *directly at the beginning* of the next cycle.
>   => Move?

> * Unique Joins
>   This seems to require more work and came in pretty late
>   => Returned with feedback.
>
> * INNER JOIN removals
>   Seem far to controversial to consider comitting in 9.5.
>   => Returned (or even rejected :()

> * Async execution of postgres_fdw.
>   Later iterations of the patch haven't gotten much review yet. The
>   original version of the patch is just from 2014-12-15.
>   => Should imo be moved to the next CF

> 
> * Allow "snapshot too old" error, to prevent bloat
>   http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.com
>   talked about a new version that afaics never materialized
>   => Returned with feedback

> * Parallel Seq scan
>   In my opinion the topic has progressed greatly. But at the same time
>   it doesn't seem like it's in a state we should consider for 9.5.
>   => Return?

> * logical column ordering (WIP)
>   This pretty clearly isn't 9.5 material.
>   => Return

> * Support ORDER BY in CREATE FUNCTION for Set Returning Functions
>   Uhm. I think the outcome of the discussion so far wasn't really
>   favorable to the idea s proposed.
>   => Rejected

Marked as such.