Re: [PERFORM] Help speeding up delete

Scott Lamb wrote: > On Nov 14, 2005, at 3:52 PM, Steve Wampler wrote: > >> Scott Lamb wrote: >> >>> On Nov 14, 2005, at 2:07 PM, Steve Wampler wrote: >>> # SELECT at.id FROM "tmp_table2" at, "tmp_tabl2e" a # WHERE at.id=a.id and a.name='obsid' and a.value='oid080505'; >>> >>> >>> >>> I

Re: [PERFORM] Help speeding up delete

On Nov 14, 2005, at 3:52 PM, Steve Wampler wrote: Scott Lamb wrote: On Nov 14, 2005, at 2:07 PM, Steve Wampler wrote: # SELECT at.id FROM "tmp_table2" at, "tmp_tabl2e" a # WHERE at.id=a.id and a.name='obsid' and a.value='oid080505'; Isn't this equivalent? select id from tmp_table2 where

Re: [PERFORM] Help speeding up delete

Joshua Marsh wrote: > > > On 11/14/05, *Steve Wampler* <[EMAIL PROTECTED] > > wrote: > > However, even that seems to have a much higher cost than I'd expect: > >lab.devel.configdb=# explain delete from "tmp_table2" where id in > (select id from

Re: [PERFORM] Help speeding up delete

On 11/14/05, Steve Wampler <[EMAIL PROTECTED]> wrote: However, even that seems to have a much higher cost than I'd expect:   lab.devel.configdb=# explain delete from "tmp_table2" where id in(select id from tmp_table2 where name='obsid' and value = 'oid080505');    NOTICE:  QUERY PLAN:   Seq

Re: [PERFORM] Help speeding up delete

Tom Lane wrote: > Steve Wampler <[EMAIL PROTECTED]> writes: > >>We've got an older system in production (PG 7.2.4). Recently >>one of the users has wanted to implement a selective delete, >>but is finding that the time it appears to take exceeds her >>patience factor by several orders of magnitud

Re: [PERFORM] Postgres recovery time

Piccarello, James (James) wrote: Postgres recovery time Does anyone know what factors affect the recovery time of postgres if it does not shutdown cleanly? With the same size database I've seen  times from a few seconds to a few minutes. The longest time was 33 minutes. The 33 minut

[PERFORM] Hardware/OS recommendations for large databases (5TB)

Does anyone have recommendations for hardware and/or OS to work with around 5TB datasets?   The data is for analysis, so there is virtually no inserting besides a big bulk load. Analysis involves full-database aggregations - mostly basic arithmetic and grouping. In addition, much smaller 

Re: [PERFORM] Help speeding up delete

Scott Lamb wrote: > On Nov 14, 2005, at 2:07 PM, Steve Wampler wrote: > >> # SELECT at.id FROM "tmp_table2" at, "tmp_tabl2e" a >> # WHERE at.id=a.id and a.name='obsid' and a.value='oid080505'; > > > Isn't this equivalent? > > select id from tmp_table2 where name = 'obsid' and value = 'oid0805

Re: [PERFORM] Performance PG 8.0 on dual opteron / 4GB / 3ware Raid5 / Debian??

Joost, I've got experience with these controllers and which version do you have. I'd expect to see higher than 50MB/s although I've never tried RAID 5 I routinely see closer to 100MB/s with RAID 1+0 on their 9000 series I would also suggest that shared buffers should be higher than 7500,

Re: [PERFORM] Help speeding up delete

Steve Wampler <[EMAIL PROTECTED]> writes: > We've got an older system in production (PG 7.2.4). Recently > one of the users has wanted to implement a selective delete, > but is finding that the time it appears to take exceeds her > patience factor by several orders of magnitude. Here's > a synops

Re: [PERFORM] Help speeding up delete

On Nov 14, 2005, at 2:07 PM, Steve Wampler wrote: # SELECT at.id FROM "tmp_table2" at, "tmp_tabl2e" a # WHERE at.id=a.id and a.name='obsid' and a.value='oid080505'; Isn't this equivalent? select id from tmp_table2 where name = 'obsid' and value = 'oid080505'; # DELETE FROM "tmp_table2" WHE

[PERFORM] Help speeding up delete

We've got an older system in production (PG 7.2.4). Recently one of the users has wanted to implement a selective delete, but is finding that the time it appears to take exceeds her patience factor by several orders of magnitude. Here's a synopsis of her report. It appears that the "WHERE id IN

[PERFORM] Postgres recovery time

Title: Postgres recovery time Does anyone know what factors affect the recovery time of postgres if it does not shutdown cleanly? With the same size database I've seen  times from a few seconds to a few minutes. The longest time was 33 minutes. The 33 minutes was after a complete system crash

Re: [PERFORM] slow queries after ANALYZE

DW wrote: Hello, I'm perplexed. I'm trying to find out why some queries are taking a long time, and have found that after running analyze, one particular query becomes slow. This query is based on a view that is based on multiple left outer joins to merge data from lots of tables. If I d

Re: [PERFORM] 8.x index insert performance

At 09:43 AM 11/14/2005, Kelly Burkhart wrote: On Fri, 2005-11-11 at 18:02 -0500, Tom Lane wrote: > > There very well could be a pattern in the data which could affect > > things, however, I'm not sure how to identify it in 100K rows out of > > 100M. > > I conjecture that the problem areas represe

Re: [PERFORM] 8.x index insert performance

On Fri, 2005-11-11 at 18:02 -0500, Tom Lane wrote: > > There very well could be a pattern in the data which could affect > > things, however, I'm not sure how to identify it in 100K rows out of > > 100M. > > I conjecture that the problem areas represent places where the key > sequence is significa