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 shar
On 02/11/2012 07:53 PM, Jeff Janes wrote:
Has it ever been well-characterized what the problem is with>8GB?
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 o
On Tue, Feb 7, 2012 at 4:58 PM, 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 buffer
On Tue, Feb 7, 2012 at 2:06 PM, 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
> mu
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 h
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 h
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 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 characteris
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
(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 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 surpr
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
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
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..
Certa
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 (pgs
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 q
On Thu, Jan 5, 2012 at 5:04 AM, Benedikt Grundmann
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 need to post EXPLAIN ANALY
Hello list,
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 surprised me a bit as I had thought th
18 matches
Mail list logo
