On Mon, 2007-10-22 at 19:24 -0700, Adrian Demaestri wrote:
> Hi,
> I think planner should use other plans than seqscan to solve querys
> like select * from hugetable limit 1, especially when the talbe is
> very large. Is it solved in newer versions or is there some open
> issues about it?.
> than
Hi,
I think planner should use other plans than seqscan to solve querys like select
* from hugetable limit 1, especially when the talbe is very large. Is it solved
in newer versions or is there some open issues about it?.
thanks
I'm working with postgres 8.0.1,
>>> On Mon, Oct 22, 2007 at 11:10 AM, in message
<[EMAIL PROTECTED]>, Lee Keel
<[EMAIL PROTECTED]> wrote:
> there will probably be no more than 50 simultaneous requests.
> Dual-Quad Core 2.33GHz
My benchmarks have indicated that you want to keep the number of
active queries at or below four tim
Peter Koczan wrote:
> The
> basic rule of thumb for shared_buffers is 25%-50% of main memory,
> enough to use main memory but leaving some to allow work_mem to do its
> thing and allow any other programs to run smoothly. Tweak this as
> necessary.
Another rule of thumb is that on Windows you want
You may find this informative:
http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
On Mon, 22 Oct 2007, Lee Keel wrote:
I have a client server that is dedicated to being a Postgres 8.2.4 database
server for many websites. This server will contain approximately 15
databases each co
I recently tweaked some configs for performance, so I'll let you in on
what I changed.
For memory usage, you'll want to look at shared_buffers, work_mem, and
maintenance_work_mem. Postgres defaults to very low values of this,
and to get good performance and not a lot of disk paging, you'll want
to
I have a client server that is dedicated to being a Postgres 8.2.4 database
server for many websites. This server will contain approximately 15
databases each containing between 40-100 tables. Each database will have
approximately 7 web applications pulling data from it, but there will
probably b
