Hi,
I've experienced that PG up to current release does not make use of an index when
aggregating. Which of course may result in unacceptable answering times
This behaviour is reproducable on any table with any aggregat function in all of my
databases on every machine (PostgreSQL 7.4.2 on i386-
Frank,
> I understand tuning PG is almost an art form, yet it should be based on
> actual usage patterns, not just by system dimensions, don't you agree?
Well, it's both. It's more that available RAM determines your *upper* limit;
that is, on Linux, you don't really want to have more than 20%
On Mon, 2004-06-28 at 14:40, Josh Berkus wrote:
> As one of the writers of that article, let me point out:
>
> " -- Medium size data set and 256-512MB available RAM: 16-32MB (2048-4096)
> -- Large dataset and lots of available RAM (1-4GB): 64-256MB (8192-32768) "
>
> While this is probably a lit
Frank,
> Doug said the same, yet the PG Tuning article recommends not make this
> too large as it is just temporary used by the query queue or so. (I
> guess the system would benefit using more memory for file system cache)
As one of the writers of that article, let me point out:
" -- Medium siz
2004-06-28 07:48, Tom Lane wrote:
Klint Gore <[EMAIL PROTECTED]> writes:
On Sun, 27 Jun 2004 23:29:46 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
[yawn...] Cast the constants to bigint. See previous discussions.
[ct]
Thanks a lot guys. The term "Cast the constants to bigint" It is what I
w
Okso here lies the output of oclh (i.e "\d oclh")
Table "public.oclh"
Column | Type | Modifiers
+---+---
symbol | character varying(10) | not null default ''
date | date
Tom,
> So while he surely should not go back to 40, it seems there's another
> factor involved here that we've not recognized yet.
I'd agree. Actually, the first thing I'd do, were it my machine, is reboot it
and run memtest86 overnight.CPU thrashing like that may indicate bad RAM.
If the
Bill wrote:
Actually, I have some queries that are slow, however I was wondering if you
could help me write a query that is rather simple, but I, as a true database
novice, can't seem to conjure. So we have stocks, as I have previously
said, and I have a huge table which contains all of the openin
