Re: [HACKERS] feature freeze and beta schedule
On 1 May 2015 at 18:05, Simon Riggs si...@2ndquadrant.com wrote: * 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 OK, completely happy with this now and will commit today. It's finally ready now, but I have a meeting, so don't want to turn buildfarm red and not have time to fix. Will be committing in about 5-6 hours time. -- Simon Riggshttp://www.2ndQuadrant.com/ http://www.2ndquadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
Re: [HACKERS] feature freeze and beta schedule
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On Fri, May 1, 2015 at 1:16 PM, Stephen Frost sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On Tue, May 5, 2015 at 3:47 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, May 1, 2015 at 1:16 PM, Stephen Frost sfr...@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. Thanks for highlighting that somebody was actually trying to get my attention in that thread. I missed it :) Which brings the point - this should be discussed in a separate thread, really. It's not part of feature freeze or beta schedule... It's more about process... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Re: [HACKERS] feature freeze and beta schedule
2015-05-02 1:37 GMT+09:00 Andres Freund and...@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 kai...@kaigai.gr.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On Fri, May 1, 2015 at 5:27 PM, Andrew Gierth and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
Andres == Andres Freund and...@anarazel.de writes: Andres * Abbreviated key support for Datum sorts Andres Unfortunately the discussion about potential performance Andres regression has been largely sidestepped by bickering over Andres 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On Fri, May 1, 2015 at 10:07 PM, Andres Freund and...@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. Thanks. Here's my thoughts: * 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 intend to work on this patch for next CF, so accordingly I have moved it. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] feature freeze and beta schedule
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
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 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? * 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 probably doesn't matter that much. = Move? * Abbreviated key support for Datum sorts Unfortunately the discussion about potential performance regression has been largely sidestepped 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 that this 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.com talked about a new 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 ugly to 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 to have 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 still a 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 state we 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 around locking left. I have a hard time believing we have the cycles to resolve those for 9.5. It'd be neat if we could, but I 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't really favorable to the idea s proposed. = Rejected * RLS: row-level security, more review More of a placeholder item. There seem to various open items.
Re: [HACKERS] feature freeze and beta schedule
On 2015-05-01 13:05:19 -0400, Simon Riggs wrote: On 1 May 2015 at 12:37, Andres Freund and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
Andres,
* Andres Freund (and...@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
signature.asc
Description: Digital signature
Re: [HACKERS] feature freeze and beta schedule
- Original Message -
From: Stephen Frost sfr...@snowman.net
To: Andres Freund and...@anarazel.de
Cc: Peter Eisentraut pete...@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 (and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Re: [HACKERS] feature freeze and beta schedule
On Fri, May 1, 2015 at 9:37 AM, Andres Freund and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On 1 May 2015 at 12:37, Andres Freund and...@anarazel.de wrote: * fastbloat Not too big, I think it should be easy to commit this. = Keep in 'ready for committer' Will commit soon * 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? Yes, move * 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 * 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? Hope so * 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 -- Simon Riggshttp://www.2ndQuadrant.com/ http://www.2ndquadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
Re: [HACKERS] feature freeze and beta schedule
On 2015-05-01 09:49:50 -0700, Peter Geoghegan wrote: On Fri, May 1, 2015 at 9:37 AM, Andres Freund and...@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.4090...@2ndquadrant.com not worth a discussion? I don't see your response in http://www.postgresql.org/message-id/cam3swzty9fmrn9q8umsqn9bnedtjk68fkitomhhsxy2koyv...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
Stephen Frost sfr...@snowman.net wrote: Andres Freund (and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On Fri, May 1, 2015 at 1:55 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature freeze and beta schedule
On Thu, Apr 30, 2015 at 8:39 AM, Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
