Re: Use cases

In case you missed it:

In 8.2 the settings initdb makes as a default for shared_buffers and 
max_fsm_pages will be significantly higher if the machine can stand it. 
This should have some good performance impact on the "out of the box" 
configuration.

Frankly - supplying more sample configs is likely to be fairly 
fruitless. A much better thing would be a really good tuning tool that 
would take stats and logs and other stuff from a running server and 
suggest improvements (e.g. add an index on fields (foo,bar) on baz, try 
doubling work_mem, increase stats buckets on blurfl  ...)

The "benchmark" referred to is so full of holes it's hard to know where 
to start.

Database benchmarks are things that many years of study have gone into - 
this sort of homegrown effort is rather like a backyard attempt to 
construct a Maserati. The lack of any testing of concurrency is very 
telling.

cheers

andrew

Mark Woodward wrote:

>I think we've talked about this a couple times over the years, but I'm not
>sure it was resolved or not.
>
>The message post about load testing and SQLite showed PostgreSQL poorly.
>Yea, I know, it was the Windows port not being optimized, I can see that,
>but it raises something else. A good set of baselines for people to build
>from.
>
>Use cases: What you you intend to use PostgreSQL for.
>
>Maybe it is a set of example postgresql.conf files that have various uses,
>maybe it is a set of documtation, maybe a set of custom analyzer queries,
>and more likely a combination of all of these.
>
>One of the things that makes this interesting is that the staated goals of
>the use cases and the actual settings will be exposed to a wider audience
>and hence have a better chance of being further refined by people with
>more experience with different aspects of postgresql.
>
>We could provide whole postgresql.conf files for specific hardware
>targets, sql scripst to alter settings, and maybe custom analyzers.
>
>For instance:
>Data loading: a configuration that will restore a pg_dump file or accept
>data loading very fast.
>
>Small footprint, limited resources.
>
>Large server, large tables.
>
>Large server, many small databases
>
>Giant server, many large tables, possily many databases.
>
>High speed static server, "balls to the wall" speed, super optimized for
>query speed.
>
>High speed dynamic server, fast as possible read/write.
>
>Any other suggestions?
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: explain analyze is your friend
>
>  
>