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 Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith(at)gregsmith(dot)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