On Tue, Feb 07, 2012 at 07:58:28PM -0500, Bruce Momjian wrote:
I was initially concerned that tuning advice in this part of the docs
would look out of place, but now see the 25% shared_buffers
recommentation, and it looks fine, so we are OK. (Should we caution
against more than 8GB of shared
On 02/11/2012 07:53 PM, Jeff Janes wrote:
Has it ever been well-characterized what the problem is with8GB?
I've used shared buffers above that size for testing purposes and
could never provoke a problem with it.
If anyone ever manages to characterize it well, we might actually make
progress
On Tue, Feb 7, 2012 at 2:06 PM, Greg Smith g...@2ndquadrant.com wrote:
On 02/07/2012 03:23 PM, Bruce Momjian wrote:
Where did you see that there will be an improvement in the 9.2
documentation? I don't see an improvement.
I commented that I'm hoping for an improvement in the documentation
On Tue, Feb 7, 2012 at 4:58 PM, Bruce Momjian br...@momjian.us wrote:
I was initially concerned that tuning advice in this part of the docs
would look out of place, but now see the 25% shared_buffers
recommentation, and it looks fine, so we are OK. (Should we caution
against more than 8GB of
On 07/02/12 19:58, Bruce Momjian wrote:
On Tue, Feb 07, 2012 at 05:06:18PM -0500, Greg Smith wrote:
On 02/07/2012 03:23 PM, Bruce Momjian wrote:
Where did you see that there will be an improvement in the 9.2
documentation? I don't see an improvement.
I commented that I'm hoping for an
On Wed, Jan 11, 2012 at 08:26:52AM +, Benedikt Grundmann wrote:
(replying just to you)
On 10/01/12 15:22, Greg Smith wrote:
On 1/5/12 5:04 AM, Benedikt Grundmann wrote:
That sort of thing is one reason why all attempts so far to set
random_page_cost based on physical characteristics
On 02/07/2012 03:23 PM, Bruce Momjian wrote:
Where did you see that there will be an improvement in the 9.2
documentation? I don't see an improvement.
I commented that I'm hoping for an improvement in the documentation of
how much timing overhead impacts attempts to measure this area better.
On Tue, Feb 07, 2012 at 05:06:18PM -0500, Greg Smith wrote:
On 02/07/2012 03:23 PM, Bruce Momjian wrote:
Where did you see that there will be an improvement in the 9.2
documentation? I don't see an improvement.
I commented that I'm hoping for an improvement in the documentation
of how much
(replying just to you)
On 10/01/12 15:22, Greg Smith wrote:
On 1/5/12 5:04 AM, Benedikt Grundmann wrote:
That sort of thing is one reason why all attempts so far to set
random_page_cost based on physical characteristics haven't gone
anywhere useful. The setting is sort of overloaded right
On 11/01/12 08:26, Benedikt Grundmann wrote:
(replying just to you)
Clearly I didn't. Sigh. Getting myself a coffee now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/5/12 5:04 AM, Benedikt Grundmann wrote:
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
Emails in this mailing lists archive seem to indicate that
1.0 vs 3.0 - 4.0 are appropriate values on modern hardware.
Which
On 07/01/12 23:01, Peter Eisentraut wrote:
On tor, 2012-01-05 at 10:04 +, Benedikt Grundmann wrote:
We have recently upgrade two of our biggest postgres databases
to new hardware and minor version number bump (8.4.5 - 8.4.9).
We are experiencing a big performance regression in some
On tor, 2012-01-05 at 10:04 +, Benedikt Grundmann wrote:
We have recently upgrade two of our biggest postgres databases
to new hardware and minor version number bump (8.4.5 - 8.4.9).
We are experiencing a big performance regression in some queries.
In those cases the planner seems to
On Thu, Jan 5, 2012 at 5:04 AM, Benedikt Grundmann
bgrundm...@janestreet.com wrote:
We are experiencing a big performance regression in some queries.
In those cases the planner seems to choose a nested loop index
scan instead of hashing the index once and then joining.
I think you probably
On 05/01/12 10:04, Benedikt Grundmann wrote:
As a counter measure we are experimenting with
enable_nestloop = off
random_page_cost = 20 (instead of the previous 4).
For what it is worth we had to revert the enable_nestloop = off
change. It just moved the pain around by making other
On 2012-01-05 10:04, Benedikt Grundmann wrote:
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
It'd be really nice if the DBMS measured actual experienced values..
--
Jeremy
--
Sent via pgsql-hackers mailing list
On 1/5/12 3:00 PM, Jeremy Harris wrote:
On 2012-01-05 10:04, Benedikt Grundmann wrote:
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
It'd be really nice if the DBMS measured actual experienced values..
Certainly
17 matches
Mail list logo
