I have just moved a database to a new server and new version of Postgres
(7.1.2 to 7.3.4). The new server is much more powerful (2GB RAM, 2xXeon,
RAID) than the old one (1GB RAM, 1 CPU, single drive) and I would expect at
least twice the performance if not more, however, it is constantly showing
hi
why I should change things in
the environment)
Thanks a lot,
Bojan
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bojan Belovic <[EMAIL PROTECTED]> writes:
> > One quick question - you mentioned I should upgrade to 7.1.3 beofre I run
> > vacuum again. What are the known p
Every once in a while I'll spot a query that is taking unusually long time
to run (a chiled process that keeps the processor at 100% for like 3
minutes). Is there a way to see the queries currently executing and/or kill
a single process without affecting the operation of the server (I'm not
sure,
Related question regarding this config file and some other suggestions in this
thread. I have a similar configuration that I'm constantly tuning based on my
experience and comments I read in various places. So far, based on what I
"learned" these parameters would seem way to high for 1GB configura
timizer=CHOOSE (Cost=63 Card=1 Bytes=15)
>SORT (GROUP BY)
> HASH JOIN (Cost=63 Card=8943 Bytes=134145)
>INDEX (RANGE SCAN) OF STATION_SUBGENRE_PK (UNIQUE) (Cost=3 Card=12
> Bytes=84)
>TABLE ACCESS (FULL) OF SSA_CANDIDATE (Cost=59 Card=60364
> Bytes=482912)
&
Not sure about tuning, but it seems to me that this query would be much more
effective if it's rewritten like this (especially if style_id columns on both
tables are indexed):
SELECT count(DISTINCT song_id) AS X
FROM ssa_candidate SC JOIN station_subgenre SS ON SC.style_id = SS.style_id
WHERE SS.
