On Tue, Jan 31, 2006 at 03:11:50PM -0800, Jeffrey W. Baker wrote:
> On Tue, 2006-01-31 at 17:06 -0600, Jim C. Nasby wrote:
> > On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> > > Random page cost - should possible to determine this at runtime
> >
> > Before worrying about rando
On Tue, 2006-01-31 at 17:06 -0600, Jim C. Nasby wrote:
> On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> > Random page cost - should possible to determine this at runtime
>
> Before worrying about random_page_cost at all it makes a lot more sense
> to look at the query cost est
On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> Random page cost - should possible to determine this at runtime
Before worrying about random_page_cost at all it makes a lot more sense
to look at the query cost estimates, some of which are pretty far out of
wack.
--
Jim C. Nasb
Jeffrey,
> I agree that some instrumentation of the backend might be needed. But
> several of the performance-critical parameters seem tractable:
>
> Effective cache size - should be easy to monitor the system for this
> Shared buffers - easy to start from a rule-of-thumb and monitor usage
> Work
On Tue, 2006-01-31 at 12:11 -0800, Josh Berkus wrote:
> Jeffery,
>
> > > PostgreSQL *desperately* needs a better means of dealing with
> > > configuration (though I guess I shouldn't be pushing too hard for this
> > > since the current state of affairs brings me business). Any
> > > improvement in
Jeffery,
> > PostgreSQL *desperately* needs a better means of dealing with
> > configuration (though I guess I shouldn't be pushing too hard for this
> > since the current state of affairs brings me business). Any
> > improvement in this area would be very welcome.
> > http://pgfoundry.org/project
