Being new to Postgres, I understand how frustrating tuning is. I've been
working on some very basic queries, and trying to get some decent performance.
I know the problem isn't with io on the system, since I can use other tests
that far exceed the amount of data being written through postgres, so I can
only assume that the rdbms needs to be tuned.
even beyond doing different configuration files (as mysql does, fyi), just
having 'guidelines' for where to start with tuning the various items in
postresql.conf would be helpful. Something like
foo_val = 100 # 0-1024; higher numbers for more complex queries
I don't think that'd be too difficult. Anyone who's worked with a database
of any type, understands that tuning needs to happen.
Having the three different sizes of servers (as suggested below) would be
helpful. MySQL does this, and i've used their default configurations in the
past to help me troubleshoot probllems i was having with a complex query on
sub-standard hardware. After changing some of the values around, the query
ran slowly, but it actually ran, whereas before, it didn't.
Slightly off subject, as I've been advocating use of Postgres, and people
have been trying it, some of the quirks that one runs into when goinng from
rdbms to rdbms are frustrating as well. Granted, these things happen with
going from any rdbms to another, but it'd be nice if there were a guide to say
something like, in MySQL, you use 'show tables from tablename', and in
Postgres, you use \d tablename to achieve the same results.
Just my $.02 worth.
Tim
On Fri, Jul 04, 2003 at 03:39:57PM -0500, johnnnnnn wrote:
> On Fri, Jul 04, 2003 at 10:49:01AM -0400, Rod Taylor wrote:
> > > In my opinion the defaults should be set up for a typical database
> > > server machine.
> >
> > Ok.. thats fair. The first problem would be to define typical for
> > current PostgreSQL installations, and typical for non-postgresql
> > installations (the folks we want to convert).
>
> It's been a while since the last one of these discussions, so stop me
> if this has been suggested before, but...
>
> Do we actually want to have a default configuration file?
>
> Seriously, if we provide, say, 4 or 5 files based on various system
> assumptions (conf.MINIMAL, conf.AVERAGE, conf.MULTIDISK, or whatever),
> then we might be able to get away with not providing an actual
> default. Change the installation instructions to say
>
> >>>
> PostgreSQL requires a configuration file, which it expects to be
> located in $DIR. Provided are several example configurations (in
> $DIR/eg/). If you're just starting with PostrgreSQL, we recommend
> reading through those and selecting one which most closely matches
> your machine.
>
> If you're in doubt as to which file to use, try $AVERAGE. If you're
> still having difficulty getting PostgreSQL to run, try
> $MINIMAL. $MINIMAL should work on every supported platform, but is not
> optimized for modern hardware -- PostgreSQL will not run well in this
> configuration.
> <<<
>
> This makes the installation process slightly less simple, but only in
> the way that we want it to be. That is, it forces the end user to the
> realization that there actually is configuration to be done, and
> forces them into a minimally interactive way to deal with it.
>
> It also doesn't require any kernel-test coding, or really any
> development at all, so we should theoretically be able to get it
> finished and ready to go more quickly.
>
> Thoughts?
>
> -johnnnnnnnnnnn
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
