Re: [ADMIN] PANIC killing vacuum process

Silvio Brandani ha scritto: Kevin Grittner ha scritto: Scott Marlowe scott.marl...@gmail.com wrote: Silvio Brandani silvio.brand...@tech.sdb.it wrote: we have develop a script to execute the vacuum full on all tables Vacuum full is more of a recovery / offline command

Re: [ADMIN] Disk Performance Problem on Large DB

Correct, with a single drive and no write cache, once you get more than 1 I/O running simultaneously, i.e. 1 writing the data and 1 writing each index = 5 I/Os at once, you effectively devolve to your drives random I/O rate which can be an order of magnitude slower than its sequential I/O rate.

Re: [ADMIN] PANIC killing vacuum process

Silvio Brandani silvio.brand...@tech.sdb.it wrote: the postgres 9.0.x could be consider a stable version ?? or is better to wait 9.1 , in this case when will be released ?? You would gain nothing by waiting for 9.1. 9.0.x is no more or less a stable version than 8.3.x. It's the x which

[ADMIN] Get Postgres to use multiple proc cores?

With my hard drive issues from an earlier email solved (thanks all) I am now running queries against my 65M rows. I noticed in atop that postmaster is using 100% of just one processor core. Is there any way to tell it to use both (or at least some of the other one). System is RHEL5, PG is

Re: [ADMIN] Get Postgres to use multiple proc cores?

On Fri, Nov 5, 2010 at 8:59 AM, Jonathan Hoover jhoo...@yahoo-inc.com wrote: With my hard drive issues from an earlier email solved (thanks all) I am now running queries against my 65M rows. I noticed in atop that postmaster is using 100% of just one processor core. Is there any way to tell

Re: [ADMIN] Get Postgres to use multiple proc cores?

Scott, I'd like to take this chance to ask another (related though) question. What is faster? A JOIN or a WHERE a IN (SELECT ... ) I've heard that the nested subquery has a tendency to be slower, but I'd like to check it with people from the list. Is one faster than the other? Or, all in

Re: [ADMIN] Get Postgres to use multiple proc cores?

On Fri, Nov 5, 2010 at 9:29 AM, Oliveiros d'Azevedo Cristina oliveiros.crist...@marktest.pt wrote: Scott, I'd like to take this chance to ask another (related though) question. What is faster? A JOIN or a WHERE a IN (SELECT ... ) I've heard that the nested subquery has a tendency to be

Re: [ADMIN] Get Postgres to use multiple proc cores?

Oliveiros d'Azevedo Cristina oliveiros.crist...@marktest.pt wrote: What is faster? A JOIN or a WHERE a IN (SELECT ... ) On 8.4 and later an EXISTS or NOT EXISTS will use semi-join or anti-join (respectively). These should usually be much faster than the IN (SELECT DISTINCT ... ) technique.