Added to TODO:
* Consider transaction start/end performance improvements
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php
http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php
---
Thread URL added to TODO:
* SMP scalability improvements
---
Paul van den Bogaard wrote:
Just started a blog session on my findings running Postgres 8.3(beta)
on a mid range Sun Fire server. Second entry is
Just started a blog session on my findings running Postgres 8.3(beta)
on a mid range Sun Fire server. Second entry is about the time lost
on LWLock handling. When concurrency increases you can see the
ProcArrayLock wait queue to start and explode.
Just started a blog session on my findings running Postgres 8.3(beta)
on a mid range Sun Fire server. Second entry is about the time lost
on LWLock handling. When concurrency increases you can see the
ProcArrayLock wait queue to start and explode.
On Tue, 2008-03-11 at 20:23 -0400, Bruce Momjian wrote:
Is this still a TODO?
I think so.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Simon Riggs wrote:
On Tue, 2008-03-11 at 20:23 -0400, Bruce Momjian wrote:
Is this still a TODO?
I think so.
How about this wording:
Review Simon's claims to improve performance
;-)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company -
Alvaro Herrera wrote:
Simon Riggs wrote:
On Tue, 2008-03-11 at 20:23 -0400, Bruce Momjian wrote:
Is this still a TODO?
I think so.
How about this wording:
Review Simon's claims to improve performance
What sort of evidence is usually compelling? It seems to me that
Mark Mielke [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
How about this wording:
Review Simon's claims to improve performance
What sort of evidence is usually compelling? It seems to me that this
sort of change only benefits configurations with dozens or more CPUs/cores?
The main point
Is this still a TODO?
---
Simon Riggs wrote:
On Mon, 2007-07-30 at 20:20 +0100, Simon Riggs wrote:
Jignesh Shah's scalability testing on Solaris has revealed further
tuning opportunities surrounding the start and end
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
Jignesh Shah's scalability testing on Solaris has revealed further
tuning opportunities
Bruce Momjian wrote:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
I think the work on VIDs and latestCompletedXid make this completely
obsolete.
---
Simon
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I think the work on VIDs and latestCompletedXid make this completely
obsolete.
Please confirm, all of Simon's issues?
Not sure --- the area is certainly still worth looking at, but the
recent patches have changed things enough
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
I think the work on VIDs and latestCompletedXid make this completely
obsolete.
Please confirm, all of Simon's
Alvaro Herrera wrote:
Bruce Momjian wrote:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
I think the work on VIDs and latestCompletedXid make this completely
obsolete.
Please confirm, all of Simon's issues?
On Mon, 2007-07-30 at 20:20 +0100, Simon Riggs wrote:
Jignesh Shah's scalability testing on Solaris has revealed further
tuning opportunities surrounding the start and end of a transaction.
Tuning that should be especially important since async commit is likely
to allow much higher
Simon Riggs wrote:
1. Increase size of Clog-specific BLCKSZ
2. Perform ExtendClog() as a background activity
(1) and (2) can be patched fairly easily for 8.3. I have a prototype
patch for (1) on the shelf already from 6 months ago.
Hmm, I think (1) may be 8.3 material but all the rest are
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
1. Increase size of Clog-specific BLCKSZ
2. Perform ExtendClog() as a background activity
(1) and (2) can be patched fairly easily for 8.3. I have a prototype
patch for (1) on the shelf already from 6 months ago.
Jignesh Shah's scalability testing on Solaris has revealed further
tuning opportunities surrounding the start and end of a transaction.
Tuning that should be especially important since async commit is likely
to allow much higher transaction rates than were previously possible.
There is strong
18 matches
Mail list logo
