SEO

Few proposals

- Can we say "smoothed" rather than "distributed" checkpoints?
"Smoothed checkpoints greatly reduce checkpoint I/O spikes"

- Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
change to
"Heap-Only Tuples (HOT) improve performance of frequent UPDATEs"



I also notice that two performance features have disappeared from the
release notes. (Presumably they have been removed from source). Both of
them have changes that can be seen by users, so can't see why we would
want them removed.

- Merge Join performance has been substantially improved by ring buffer
which avoids materializing the previous sort step. (Simon, Greg)

More info, not for release notes:
The materialization of the prior sort step would generally double the
time taken for the sort, so avoiding this effectively gives a 50%
performance gain on sorts that are part of large merge joins.


- WAL file switches don't update controlfile any longer. Recovery now
refers to the last checkpoint time, which may be many minutes earlier
than time previously mentioned. (Simon, Tom)

More info, not for release notes:
WAL file switches were performed holding important LWLocks, so this
improves scalability on high end systems as well as reducing response
time spikes under heavy load on all kinds of hardware.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Fri, 2007-11-30 at 06:31 +0000, Simon Riggs wrote:

> I also notice that two performance features have disappeared from the
> release notes. (Presumably they have been removed from source). Both of
> them have changes that can be seen by users, so can't see why we would
> want them removed.

Wow, just realised 3 of Heikki's performance patches aren't mentioned
either:

- CheckpointStartLock removal

- I/O reduction during recovery

- Tuning of Visibility code

I'm not sure what the rationale is for not mentioning these things.
They're at least as important, if not more so, than mentioning minor
source code changes.

If people understand there aren't 13 performance improvements there are
at *least* 19+ that is a positive message to help people decide to
upgrade.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Simon Riggs" <simon@2ndquadrant.com> writes:

> If people understand there aren't 13 performance improvements there are
> at *least* 19+ that is a positive message to help people decide to
> upgrade.

Frankly I think the release notes are already too long. People who judge a
release by counting the number of items in the release notes are not worth
appeasing. Including every individual lock removed or code path optimized will
only obscure the important points on which people should be judging the
relevance of the release to them. Things like smoothing checkpoint i/o which
could be removing a show-stopper problem for them.

If they're mentioned at all a single release note bullet point saying "Many
optimizations and concurrency improvements in areas such as transaction start
and finish, checkpoint start, record visibility checking, merge join plans,
...." would suffice.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 11/30/07, Gregory Stark <stark@enterprisedb.com> wrote:
>
>
> "Simon Riggs" <simon@2ndquadrant.com> writes:
>
> > If people understand there aren't 13 performance improvements there are
> > at *least* 19+ that is a positive message to help people decide to
> > upgrade.
>
> Frankly I think the release notes are already too long. People who judge a
> release by counting the number of items in the release notes are not worth
> appeasing. Including every individual lock removed or code path optimized
> will
> only obscure the important points on which people should be judging the
> relevance of the release to them. Things like smoothing checkpoint i/o
> which
> could be removing a show-stopper problem for them.
>
> If they're mentioned at all a single release note bullet point saying
> "Many
> optimizations and concurrency improvements in areas such as transaction
> start
> and finish, checkpoint start, record visibility checking, merge join
> plans,
> ..." would suffice.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's 24x7 Postgres support!
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

i agree that release notes should not be too long, but may be there should
be (if there isn't one already) something like a "change log" where people
can find out all the changes done from the previous release, if they are
intrested ?

--
Usama Munir Dar http://linkedin.com/in/usamadar
Consultant Architect
Cell:+92 321 5020666
Skype: usamadar

On Fri, 2007-11-30 at 09:49 +0000, Gregory Stark wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
>
> > If people understand there aren't 13 performance improvements there are
> > at *least* 19+ that is a positive message to help people decide to
> > upgrade.
>
> Frankly I think the release notes are already too long.

So why do we have stuff in there that the users will never see?

We already have a release summary, so why summarise *some* of the detail
as well, but not all of it???

I see no reason to diminish yours, Heikki's or my own contributions, all
of which were in the area of performance, which people do care about.
None of the ones I mentioned were trivial patches, nor were their
effects small.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Simon Riggs wrote:
>
> - Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
> change to
> "Heap-Only Tuples (HOT) improve performance of frequent UPDATEs"
>
>
>

I think we need to qualify this, or it could be quite misleading.
perhaps add "that don't affect indexed columns" or something like that.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Nov 30, 2007 4:49 AM, Gregory Stark <stark@enterprisedb.com> wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > If people understand there aren't 13 performance improvements there are
> > at *least* 19+ that is a positive message to help people decide to
> > upgrade.
>
> Frankly I think the release notes are already too long. People who judge a
> release by counting the number of items in the release notes are not worth
> appeasing. Including every individual lock removed or code path optimized will
> only obscure the important points on which people should be judging the
> relevance of the release to them. Things like smoothing checkpoint i/o which
> could be removing a show-stopper problem for them.

IMO, it's probably good to include things that materially affect how
people operate the databse. An example is improvements to statistics
gathering because it eliminates a historical trade-off in configuring
the server. I agree with you regarding basic operations though.

merlin

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Simon Riggs wrote:
> On Fri, 2007-11-30 at 06:31 +0000, Simon Riggs wrote:
>
>> I also notice that two performance features have disappeared from the
>> release notes. (Presumably they have been removed from source). Both of
>> them have changes that can be seen by users, so can't see why we would
>> want them removed.
>
> Wow, just realised 3 of Heikki's performance patches aren't mentioned
> either:
>
> - CheckpointStartLock removal

I don't think it's worth mentioning, given that we have the Load
Distributed Checkpoints in there. That alone will tell people that
there's been some major changes to checkpoints.

> - I/O reduction during recovery

This might be worth mentioning, since it can be quite a big difference
in the right circumstances, and it helps a bit with the scalability
problem of the recovery. Should mention that it only helps with
full_pages_writes=on. One more reason to not gamble with data integrity ;-).

> - Tuning of Visibility code

I don't think that was release notes worthy.

The release notes are quite long already...

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Usama Dar" <munir.usama@gmail.com> writes:
> i agree that release notes should not be too long, but may be there should
> be (if there isn't one already) something like a "change log" where people
> can find out all the changes done from the previous release, if they are
> intrested ?

The CVS history (either direct from the CVS server, or in the
pgsql-committers archives) will give you as much detail as you could
possibly want.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Josh Berkus <josh@agliodbs.com> writes:
> I disagree. For people who want a quick summary of the major user-facing
> things changed we'll have multiple sources: (a) the announcement, (b) the
> press features list, (c) the Feature-Version matrix. The Release notes
> should have a *complete* list of changes.

Define "complete".

> Why? Because we don't use a bug/feature tracker. So a user trying to
> figure out "hey, was my issue XXX fixed so that I should upgrade?" has
> *no other source* than the Release notes to look at, except CVS
> history. And if we start asking sysadmins and application vendors to
> read the CVS history, we're gonna simply push them towards other
> DBMSes which have this information more clearly.

So in other words, you don't *really* want "complete".

This discussion is all about finding a suitable balance between length
and detail. Simplistic pronouncements don't help us strike that
balance.

FWIW, I tend to agree with the folks who think Bruce trimmed too much
this time. But the release notes are, and always have been, intended to
boil the CVS history down to something useful by eliminating irrelevant
detail. For the vast majority of people, the details that are being
mentioned here are indeed irrelevant. There will be some for whom they
are not. But depending on the question, almost any detail might not be
irrelevant, and at that point you have to be prepared to go check the
archives.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster