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?
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
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
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
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
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
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
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
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
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
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
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!
"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
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
"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
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
16 matches
Mail list logo
