Re: [PERFORM] SAN and full_page_writes

Thanks for pointing that out Bruce. NetApp has a 6 page PDF about NetApp and databases. On page 4: As discussed above, reads and writes are unconditionally atomic to 64 KB. While reads or writes may fail for a number of reasons (out of space, permissions, etc.), the failure is always atomic to 6

Re: [PERFORM] SAN and full_page_writes

"Nikolas Everett" <[EMAIL PROTECTED]> writes: > Thanks for pointing that out Bruce. > > NetApp has a 6 page PDF about NetApp and databases. On page 4: Skimming through this I think all 6 pages are critical. The sentence you quote out of context pertains specifically to the NAS internal organiza

Re: [PERFORM] SAN and full_page_writes

Sorry about that. I was having tunnel vision and pulled out the part that applied to me. I also figured that the OS and file system information was superfluous but on second look it may not be. This bit: To satisfy the Durability requirement, all write operations must write through any OS cache

Re: [PERFORM] SAN and full_page_writes

"Nikolas Everett" <[EMAIL PROTECTED]> writes: > Sounds kind of scary. I think postgres forces the underlying OS and file > system to do that stuff (sans the mutli-host magic) using fsync. Is that > right? Yes, so you have to make sure that your filesystem really does support fsync properly. I t

Re: [PERFORM] SAN and full_page_writes

On Mon, Sep 8, 2008 at 10:59 AM, Gregory Stark <[EMAIL PROTECTED]>wrote: > > That "media recovery" it's referring to sounds like precisely our WAL full > page writes... > > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's PostGIS support!

Re: [PERFORM] inaccurate stats on large tables

Hi Kiran, You gave great info on your problem. First, is this the query you're actually trying to speed up, or is it a simplified version? It looks like the optimizer has already chosen the best execution plan for the given query. Since the query has no joins, we only have to consider access

[PERFORM] bitmap heap scan versus simple index and nested loop

Preliminaries: pg 8.3.3 on ubuntu 7.10 4x1.66GHz CPUs 10G ram interesting postgresql.conf settings: max_connections = 300 shared_buffers = 3000MB work_mem = 32MB random_page_cost = 1.5 effective_cache_size = 5000MB default_statistics_target = 30 lc_messages = 'en_US.UTF-8' OK, We're running mnog

Re: [PERFORM] SAN and full_page_writes

Nikolas Everett wrote: > Thanks for pointing that out Bruce. > > NetApp has a 6 page PDF about NetApp and databases. On page 4: > > As discussed above, reads and writes are unconditionally atomic to 64 KB. > While reads or writes > may fail for a number of reasons (out of space, permissions, etc

[PERFORM] Intel's X25-M SSD

If like me you've been reading all the flash SSD drive reviews that come out, you might have also noticed that the performance on write-heavy workloads hasn't been too far ahead of traditional drives. It's typically been hit or miss as to whether the SDD would really be all that much faster on

Re: [PERFORM] Intel's X25-M SSD

On Mon, Sep 8, 2008 at 7:12 PM, Greg Smith <[EMAIL PROTECTED]> wrote: > If like me you've been reading all the flash SSD drive reviews that come > out, you might have also noticed that the performance on write-heavy > workloads hasn't been too far ahead of traditional drives. It's typically > been

Re: [PERFORM] Intel's X25-M SSD

I have been paying close attention to the recent SSD performance/price changes with a keen eye to server performance on various workloads and applications. The real barrier is in the controller design, and IP surrounding that. All flash products with any amount of wear-leveling map logical addres

[PERFORM] best use of another drive

I've recently installed another drive in my db server and was wondering what the best use of it is. Some thoughts I have are: 1. Move some of the databases to the new drive. If this is a good idea, is there a way to do this without a dump/restore? I'd prefer to move the folder if possible since t

Re: [PERFORM] best use of another drive

On Mon, Sep 8, 2008 at 8:19 PM, Rainer Mager <[EMAIL PROTECTED]> wrote: > I've recently installed another drive in my db server and was wondering what > the best use of it is. Some thoughts I have are: Being a DBA, I'd tend to say make it a mirror of the first drive. -- Sent via pgsql-performanc

Re: [PERFORM] best use of another drive

On Mon, 8 Sep 2008 22:11:25 -0600 "Scott Marlowe" <[EMAIL PROTECTED]> wrote: > On Mon, Sep 8, 2008 at 8:19 PM, Rainer Mager <[EMAIL PROTECTED]> > wrote: > > I've recently installed another drive in my db server and was > > wondering what the best use of it is. Some thoughts I have are: > > Being

Re: [PERFORM] best use of another drive

Thanks. I should have mentioned the existing disk and the new one are already both mirrored (not together, though :-p). So we had 2 drives that were mirrored and just added 2 more that are mirrored. --Rainer -Original Message- From: Joshua Drake [mailto:[EMAIL PROTECTED] Sent: Tuesday, S

Re: [PERFORM] best use of another drive

On Mon, Sep 8, 2008 at 8:19 PM, Rainer Mager <[EMAIL PROTECTED]> wrote: > 1. Move some of the databases to the new drive. If this is a good idea, is > there a way to do this without a dump/restore? I'd prefer to move the folder > if possible since that would be much faster. What like tablespaces?