On Tue, 5 Aug 2003 15:26:09 -0700, Sean Chittenden
<[EMAIL PROTECTED]> wrote:
>> I have an experimental patch lying around somewhere that tries to
>> work around these problems by offering different estimation methods
>> for index scans. If you are interested, I'll dig it out.
>
>Sure, I'll take a
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> If you CLUSTER on an index and then ANALYSE, you get a correlation of
>> 1.0 (== optimum) for the first column of the index.
> Correlating of what to what? Of data to nearby data? Of data to
> related data (ie, multi-column index?)? Of related data
> >> I have an experimental patch lying around somewhere that tries to
> >> work around these problems by offering different estimation methods
> >> for index scans. If you are interested, I'll dig it out.
> >
> >Sure, I'll take a gander... had my head in enough Knuth recently to
> >even hopefully
> >> is some other problem that needs to be solved. (I'd wonder about
> >> index correlation myself; we know that that equation is pretty
> >> bogus.)
> >
> >Could be. I had him create a multi-column index on the date and a
> >non-unique highly redundant id.
>
> Tom has already suspected index c
[jumping in late due to vacation]
On Thu, 3 Jul 2003 17:06:46 -0700, Sean Chittenden
<[EMAIL PROTECTED]> wrote:
>> is some other problem that needs to be solved. (I'd wonder about
>> index correlation myself; we know that that equation is pretty
>> bogus.)
>
>Could be. I had him create a multi-c
Keep in mind that if we auto-tune, we will only be able to do it for
some platforms, so we will need a table that shows which settings are
autotuned for each platform.
---
Sean Chittenden wrote:
> > I don't have much to add
Michael Pohl wrote:
> On Sun, 6 Jul 2003, Matthew Nuzum wrote:
>
> > At the very least, if there is good documentation for these parameters,
> > maybe the conf file should provide a link to this info.
>
> I believe that is what Josh is proposing:
>
> http://archives.postgresql.org/pgsql-perform
Sean Chittenden wrote:
I looked through the src/doc/runtime.sgml for a good place to stick
this and couldn't find a place that this seemed appropriate, but on
FreeBSD, this can be determined with a great deal of precision in a
programmatic manner:
echo "effective_cache_size = $((`sysctl -n vfs.hibu
> I don't have much to add because I'm pretty new to Postgres and have
> been soliciting advice here recently, but I totally agree with
> everything you said. I don't mind if it's in the postgres.conf file
> or in a faq that is easy to find, I just would like it to be in one
> place. A good examp
Scott Marlowe wrote:
It would be nice to have a program that could run on any OS postgresql
runs on and could report on the current limits of the kernel, and make
recommendations for changes the admin might want to make.
One could probably make a good stab at effective cache size during
instal
On Wed, 9 Jul 2003, Kaarel wrote:
> >>Are you willing to say that the PostgreSQL database system should only be
> >>used by DBAs? I believe that Postgres is such a good and useful tool that
> >>anyone should be able to start using it with little or no barrier to entry.
> >
> >
> > I quite agree
Are you willing to say that the PostgreSQL database system should only be
used by DBAs? I believe that Postgres is such a good and useful tool that
anyone should be able to start using it with little or no barrier to entry.
I quite agree. But there is a difference between saying "you should get
On Mon, Jul 07, 2003 at 10:08:50AM -0700, Chris Travers wrote:
> In my opinion, a serious RDBMS system will *always* require the admin to
> be doing research in order to learn how to use it effectively. We are
> not talking about a word processor here.
>
> That being said, I think that a good p
Matthew Nuzum wrote:
I'm highly resistant to/disappointed in this attitude and firmly
believe that there are well understood algorithms that DBAs use to
diagnose and solve performance problems. It's only a black art
because it hasn't been documented. Performance tuning isn't voodoo,
it's adjusti
"Matthew Nuzum" <[EMAIL PROTECTED]> writes:
> Are you willing to say that the PostgreSQL database system should only be
> used by DBAs? I believe that Postgres is such a good and useful tool that
> anyone should be able to start using it with little or no barrier to entry.
I quite agree. But the
> Are you willing to say that the PostgreSQL database system should only be
> used by DBAs? I believe that Postgres is such a good and useful tool that
> anyone should be able to start using it with little or no barrier
> to entry.
This is a good point. After reading previous responses I was sta
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-performance-
> [EMAIL PROTECTED] On Behalf Of Andrew Sullivan
> Sent: Monday, July 07, 2003 5:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PERFORM] Moving postgresql.conf tunables into 2003...
>
> On Sa
On Sat, Jul 05, 2003 at 02:12:56PM -0700, Sean Chittenden wrote:
> The SGML docs aren't in the DBA's face and are way out of the way for
> DBAs rolling out a new system or who are tuning the system. SGML ==
> Developer, conf == DBA.
I could not disagree more. I'd say more like, if the dba won't
Why couldn't Postgres learn for itself what the optimal performance
settings would be? The easy one seems to be the effective_cache_size.
Top shows us this information. Couldn't Postgres read that value from
the same place top reads it instead of relying on a config file value?
Seems like it
Michael Pohl wrote:
On Sun, 6 Jul 2003, Matthew Nuzum wrote:
At the very least, if there is good documentation for these parameters,
maybe the conf file should provide a link to this info.
I believe that is what Josh is proposing:
http://archives.postgresql.org/pgsql-performance/2003-07/msg00
On Sun, 6 Jul 2003, Matthew Nuzum wrote:
> At the very least, if there is good documentation for these parameters,
> maybe the conf file should provide a link to this info.
I believe that is what Josh is proposing:
http://archives.postgresql.org/pgsql-performance/2003-07/msg00102.php
> [Apache
> > This sort of narrative belongs in the SGML docs, not in a CONF file.
> > In fact, one could argue that we should take *all* commentary out of
> > the CONF file in order to force people to read the docs.
>
> The SGML docs aren't in the DBA's face and are way out of the way for
> DBAs rolling ou
>
> Brian Suggests:
> > I'm curious how many of the configuration values can be determined
> > automatically, or with the help of some script. It seem like there
> > could be some perl script in contrib that could help figure this out.
> > Possibly you are asked a bunch of questions and then the
Sean,
> > That's exactly my point. We cannot provide enough documentation in
> > the CONF file without septupling its length. IF we remove all
> > commentary, and instead provide a pointer to the documentation, more
> > DBAs will read it.
>
> Which I don't think would happen and why I think the
> > The SGML docs aren't in the DBA's face and are way out of the way
> > for DBAs rolling out a new system or who are tuning the system.
> > SGML == Developer, conf == DBA.
>
> That's exactly my point. We cannot provide enough documentation in
> the CONF file without septupling its length. IF w
Sean,
> The SGML docs aren't in the DBA's face and are way out of the way for
> DBAs rolling out a new system or who are tuning the system. SGML ==
> Developer, conf == DBA.
That's exactly my point. We cannot provide enough documentation in the CONF
file without septupling its length. IF we r
> > # The default values for PostgreSQL are extremely conservative and
> > # are likely far from ideal for a site's needs. Included in this
> > # configuration, however, are _suggested_ values to help aid in >
> > #
>
> This sort of narrative belongs in the SGML docs, not in a CONF file.
> In fa
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Getting the planner to pick
> > using the index to filter out data inserted in the last 3 days over
> > doing a seq scan... well, I don't know how you could do that without
> > changing the random_page_cost.
>
> This sounds a *whole* lot like a co
Josh Berkus <[EMAIL PROTECTED]> writes:
> Tom Comments:
>> I was arguing awhile back for bumping the default shared_buffers up,
>> but the discussion trailed off with no real resolution.
> I think we ran up against the still far-too-low SHMMAX settings in most
> *nixes. We could raise this defa
That's one heck of a poor estimate for the number of rows returned.
> -> Seq Scan on mss_fwevent (cost=0.00..223312.60 rows=168478 width=12) (actual
> time=24253.66..24319.87 rows=320 loops=1)
signature.asc
Description: This is a digitally signed message part
Josh Berkus <[EMAIL PROTECTED]> writes:
> Sean Asks:
>> What are the odds of going through and revamping some of the tunables
>> in postgresql.conf for the 7.4 release?
> Poor. The time to do this would have been 3 weeks ago, when I
> announced that I was re-organizing them and that Bruce was c
Josh Berkus <[EMAIL PROTECTED]> writes:
> Kevin Brown and I followed that up by trying to build a downloadable public
> domain database that could be used for benchmarking. However, he got an FT
> job and I got distracted by prep for 7.4. So, a little help?
BTW, OSDL (Linus' new home ;-)) is s
Sean, Tom, Rod, Michael, Brian, Ron:
I'm going to paste everything into one monumental response. So be prepared to
scroll.
Sean Asks:
> What are the odds of going through and revamping some of the tunables
> in postgresql.conf for the 7.4 release?
Poor. The time to do this would have been
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Getting the planner to pick
> using the index to filter out data inserted in the last 3 days over
> doing a seq scan... well, I don't know how you could do that without
> changing the random_page_cost.
This sounds a *whole* lot like a correlation issu
> > What are the odds of going through and revamping some of the tunables
> > in postgresql.conf for the 7.4 release?
>
> I was arguing awhile back for bumping the default shared_buffers up,
> but the discussion trailed off with no real resolution.
>
> > I was just working with someone on IRC and
> > What are the odds of going through and revamping some of the
> > tunables in postgresql.conf for the 7.4 release? I was just
> > working with someone on IRC and on their 7800 RPM IDE drives,
> > their random_page_cost was ideally suited to be 0.32: a far cry
> > from 4.
>
> I find it very ver
> I'm curious how many of the configuration values can be determined
> automatically, or with the help of some script. It seem like there
> could be some perl script in contrib that could help figure this out.
> Possibly you are asked a bunch of questions and then the values are
> computed ba
> > What are the odds of going through and revamping some of the
> > tunables in postgresql.conf for the 7.4 release? I was just
> > working with someone on IRC and on their 7800 RPM IDE drives,
> > their random_page_cost was ideally suited to be 0.32: a far cry
> > from 4. Doing so has been a wi
I'm curious how many of the configuration values can be determined
automatically, or with the help of some script. It seem like there
could be some perl script in contrib that could help figure this out.
Possibly you are asked a bunch of questions and then the values are
computed based on tha
Sean Chittenden <[EMAIL PROTECTED]> writes:
> What are the odds of going through and revamping some of the tunables
> in postgresql.conf for the 7.4 release?
I was arguing awhile back for bumping the default shared_buffers up,
but the discussion trailed off with no real resolution.
> I was just w
Hear, hear!
Well said Sean. I know that there has been disagreement about this in
the past (recommending settings, with some very good reasons), however
as a programmer/part-time DBA, something like this would be extremely
useful. Our company recently developed a web-based app for a client who
I don't have much to add because I'm pretty new to Postgres and have been
soliciting advice here recently, but I totally agree with everything you
said. I don't mind if it's in the postgres.conf file or in a faq that is
easy to find, I just would like it to be in one place. A good example of
the
On Thu, 3 Jul 2003, Sean Chittenden wrote:
> What are the odds of going through and revamping some of the tunables
> in postgresql.conf for the 7.4 release? I was just working with
> someone on IRC and on their 7800 RPM IDE drives, their
> random_page_cost was ideally suited to be 0.32: a far cry
On Thu, 2003-07-03 at 19:05, Sean Chittenden wrote:
> What are the odds of going through and revamping some of the tunables
> in postgresql.conf for the 7.4 release? I was just working with
> someone on IRC and on their 7800 RPM IDE drives, their
> random_page_cost was ideally suited to be 0.32: a
44 matches
Mail list logo
