Thread: Resolving 8.4 open items
If we are to make the proposed schedule for 8.4 (ie, wrap RC1 tomorrow) we've got to get pretty hard-nosed about closing out the open items at http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items The current list is: * do we need to worry about re-encoding file path names? There is perhaps a real issue here, but it's not been explained nearly to my satisfaction: I do not understand how we should determine which encoding should be passed to the filesystem (but surely that shouldn't vary with the per-database locale), and it's also unclear why we shouldn't assume the value of PGDATA is already in that encoding. Perhaps the issue really applies only to file paths supplied to COPY, in which case the proposed patch is fixing it in the wrong place. I think we should just punt this question to TODO. * revisit increase of default_statistics_target? Seems like the conclusion of that thread is "no". * getaddrinfo issue on AIX We need a fix for this, or at least documentation of which OS patches should be applied. * cursor stability issues I will fix this per my proposal just now. * contrib/seg and contrib/cube GiST index support have performance issues * possible bug in cover density ranking? * localeconv encoding issues Punt all these to TODO. They are pre-existing issues and 8.4 is no worse than prior releases. * BUG #4622: xpath only work in utf-8 server encoding Document this as a limitation and put it on TODO. There are also a number of documentation issues open, particularly Dimitri's work on documenting the GIST API better, but we can work on those later. We've never considered that the RC freeze applies to documentation. Objections? regards, tom lane
Tom Lane wrote: > If we are to make the proposed schedule for 8.4 (ie, wrap RC1 tomorrow) > we've got to get pretty hard-nosed about closing out the open items at > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items > > The current list is: > > * do we need to worry about re-encoding file path names? > > There is perhaps a real issue here, but it's not been explained nearly > to my satisfaction: I do not understand how we should determine which > encoding should be passed to the filesystem (but surely that shouldn't > vary with the per-database locale), and it's also unclear why we > shouldn't assume the value of PGDATA is already in that encoding. > Perhaps the issue really applies only to file paths supplied to COPY, > in which case the proposed patch is fixing it in the wrong place. > I think we should just punt this question to TODO. Is there really something new here for 8.4? Haven't we lived with this same thing previously? If it's not a regression, +1 for punting. -- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> * do we need to worry about re-encoding file path names?
> Is there really something new here for 8.4? Haven't we lived with this
> same thing previously?
Right, it's a pre-existing issue --- any misbehavior in this area goes
back to the beginning.
regards, tom lane
On 6/10/09 10:40 AM, Tom Lane wrote: > * contrib/seg and contrib/cube GiST index support have performance issues Wasn't there an issue that fixing this requires a data format change? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
Josh Berkus <josh@agliodbs.com> writes:
> On 6/10/09 10:40 AM, Tom Lane wrote:
>> * contrib/seg and contrib/cube GiST index support have performance issues
> Wasn't there an issue that fixing this requires a data format change?
Well, that means it probably doesn't get fixed till 8.5. I'm annoyed
at that, but such is life. The problem's been there since those modules
were created, so we can stand it for another release cycle.
Alternatively, we can postpone 8.4 till Oleg and Teodor have some spare
cycles to look at the patch, but who knows when that will be.
regards, tom lane
Tom, > Alternatively, we can postpone 8.4 till Oleg and Teodor have some spare > cycles to look at the patch, but who knows when that will be. Not soon. So, +1 to go ahead. If this issue has existed for several versions, and we're not getting a lot of complaints, it says that either not many people are using cube and seg or they don't notice performance issues. Mind you, if performance is terrible, then not many people *would* use cube or seg ... -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
Josh Berkus <josh@agliodbs.com> writes:
> If this issue has existed for several versions, and we're not getting a
> lot of complaints, it says that either not many people are using cube
> and seg or they don't notice performance issues.
> Mind you, if performance is terrible, then not many people *would* use
> cube or seg ...
I suspect there aren't many. What I'm more concerned about is that
people may have copied the bogus logic for use in their own datatypes.
(Which is exactly how Matthew Wakeling came to find out the problem.)
But in any case, this train is leaving the station.
regards, tom lane
Tom, > I suspect there aren't many. What I'm more concerned about is that > people may have copied the bogus logic for use in their own datatypes. > (Which is exactly how Matthew Wakeling came to find out the problem.) > But in any case, this train is leaving the station. Can we put a warning in the README for both modules not to copy them as examples? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
Josh Berkus <josh@agliodbs.com> writes:
> Tom,
>> I suspect there aren't many. What I'm more concerned about is that
>> people may have copied the bogus logic for use in their own datatypes.
>> (Which is exactly how Matthew Wakeling came to find out the problem.)
>> But in any case, this train is leaving the station.
> Can we put a warning in the README for both modules not to copy them as
> examples?
Seems a bit pointless unless we have a better example to offer instead.
regards, tom lane
On Wed, 10 Jun 2009, Tom Lane wrote: > There are also a number of documentation issues open, particularly > Dimitri's work on documenting the GIST API better, but we can work > on those later. We've never considered that the RC freeze applies > to documentation. I had a question in this area actually. I'm working on making a mini version of http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server under "Server Configuration" in the docs. Basically, make a new section titled "Performance Optimization" that provides a short list of values to tune for better performance. We've got plenty of evidence it's hard to figure out which of the knobs in the resource/query sections are the big important ones, and which sound cool but tend to be less useful. If I got that done over the next week or two, would that still be early enough to make it into 8.4? We've made a lot of progress in the last year building community consensus in this area, and I'd like to get at least an intro to that into the official docs. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith <gsmith@gregsmith.com> writes: > On Wed, 10 Jun 2009, Tom Lane wrote: >> There are also a number of documentation issues open, particularly >> Dimitri's work on documenting the GIST API better, but we can work >> on those later. We've never considered that the RC freeze applies >> to documentation. > I had a question in this area actually. I'm working on making a mini > version of http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server > under "Server Configuration" in the docs. Basically, make a new section > titled "Performance Optimization" that provides a short list of values to > tune for better performance. We've got plenty of evidence it's hard to > figure out which of the knobs in the resource/query sections are the big > important ones, and which sound cool but tend to be less useful. > If I got that done over the next week or two, would that still be early > enough to make it into 8.4? We've made a lot of progress in the last year > building community consensus in this area, and I'd like to get at least an > intro to that into the official docs. If there's actually consensus on it, it could go in post-RC, but I'm not sure we're as close as all that ... BTW, wouldn't it fit better under Performance Tips (chapter 14)? regards, tom lane
Tom, > Seems a bit pointless unless we have a better example to offer instead. intarray maybe. Or just document which logic is wrong so people don't copy that. We owe it to people to warn them. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com