On Aug 19, 2005, at 3:01 PM, Jeremiah Jahn wrote:
Rebuild in progress with just ext3 on the raid array...will see if
this
helps the access times.
From my recent experiences, I can say ext3 is probably not a great
choice for Pg databases. If you check the archives you'll see
there's a l
Dan Harris wrote:
> From my recent experiences, I can say ext3 is probably not a great
> choice for Pg databases. If you check the archives you'll see
> there's a lot of discussion about various journalling filesystems and
> ext3 usually(always?) comes up on the bottom as far as performance
>
On Sat, Aug 20, 2005 at 12:52:08AM -0600, Dan Harris wrote:
On Aug 19, 2005, at 12:55 AM, Jeffrey W. Baker wrote:
Have you considered booting your
machine with elevator=deadline?
Although I'm not the OP for this problem, I thought I'd try it out.
WOW.. this should be in a Pg tuning guide
Hi,
While testing 8.1dev I came to this:
CREATE TABLE t (
a int,
b int
PRIMARY KEY (a,b));
In that case, the index is as big as the table.
My question is is it worthwhile to have such index peformance wise.
I understand I'd loose uniqness buthas such an index any chance to be used
against seq
On Sat, Aug 20, 2005 at 01:12:15AM -0600, Dan Harris wrote:
XFS seems to be a trusted choice, followed by Reiser and JFS both
with the occasional controversy when the comparisons pop up.
And don't put the xlog on a journaled filesystem. There is no advantage
to doing so, and it will slow thing
On Sat, Aug 20, 2005 at 02:17:54PM +0300, Marko Ristola wrote:
Based on my knoledge, Ext3 is good with keeping filesystem integrity
AND data integrity while pressing the reset button. However, by
selecting data=writeback, you gain more speed, but you risk the data
integrity during a crash: Ext3
On Sat, 20 Aug 2005 ohp@pyrenet.fr wrote:
> Hi,
>
> While testing 8.1dev I came to this:
>
> CREATE TABLE t (
> a int,
> b int
> PRIMARY KEY (a,b));
>
> In that case, the index is as big as the table.
Right. Think about it: the index must store a, b, a reference to the data
in the table itself a
Michael Stone <[EMAIL PROTECTED]> writes:
> On Sat, Aug 20, 2005 at 02:17:54PM +0300, Marko Ristola wrote:
>> Based on my knoledge, Ext3 is good with keeping filesystem integrity
>> AND data integrity while pressing the reset button. However, by
>> selecting data=writeback, you gain more speed, bu
On Sat, Aug 20, 2005 at 11:08:13PM +1000, Gavin Sherry wrote:
> Of course. The idea is that, generally speaking, you're only interested in
> a small portion of the data stored in the table. Indexes store extra data
> so that they can locate the portion you're interested in faster.
I think his ques
At 04:11 PM 8/19/2005, Jeremiah Jahn wrote:
On Fri, 2005-08-19 at 14:23 -0500, John A Meinel wrote:
> Ron wrote:
> > At 01:18 PM 8/19/2005, John A Meinel wrote:
> >
> >> Jeremiah Jahn wrote:
> >> > Sorry about the formatting.
> >> >
> >> > On Thu, 2005-08-18 at 12:55 -0500, John Arbash Meinel wro
I'm just watching gnome-system-monoitor. Which after careful
consideration.and looking at dstat means I'm on CRACKGSM isn't
showing cached memory usageI asume that the cache memory usage is
where data off of the disks would be cached...?
memory output from dstat is this for a few se
On Sat, 2005-08-20 at 11:59 -0400, Ron wrote:
> At 04:11 PM 8/19/2005, Jeremiah Jahn wrote:
> >On Fri, 2005-08-19 at 14:23 -0500, John A Meinel wrote:
> > > Ron wrote:
> > > > At 01:18 PM 8/19/2005, John A Meinel wrote:
> > > >
> > > >> Jeremiah Jahn wrote:
> > > >> > Sorry about the formatting.
>
On Fri, 2005-08-19 at 16:03 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > On Fri, 2005-08-19 at 12:18 -0500, John A Meinel wrote:
> >
> >>Jeremiah Jahn wrote:
> >>
>
>
> ...
>
> >>
> >>Well, in general, 3ms for a single lookup seems really long. Maybe your
> >>index is bloated by not va
At 02:53 PM 8/20/2005, Jeremiah Jahn wrote:
On Fri, 2005-08-19 at 16:03 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > On Fri, 2005-08-19 at 12:18 -0500, John A Meinel wrote:
> >
>
> > it's cached alright. I'm getting a read rate of about 150MB/sec. I would
> > have thought is would be f
I'm reposting this because my mailer hiccuped when I sent it the
first time. If this results in a double post, I apologize.
At 02:53 PM 8/20/2005, Jeremiah Jahn wrote:
On Fri, 2005-08-19 at 16:03 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > On Fri, 2005-08-19 at 12:18 -0500, John A M
At 02:16 PM 8/20/2005, Jeremiah Jahn wrote:
I'm just watching gnome-system-monoitor. Which after careful
consideration.and looking at dstat means I'm on CRACKGSM isn't
showing cached memory usageI asume that the cache memory usage
is where data off of the disks would be cached...?
Jeremiah Jahn wrote:
I'm just watching gnome-system-monoitor. Which after careful
consideration.and looking at dstat means I'm on CRACKGSM isn't
showing cached memory usageI asume that the cache memory usage is
where data off of the disks would be cached...?
Well a simple "free" al
Ron wrote:
At 02:53 PM 8/20/2005, Jeremiah Jahn wrote:
On Fri, 2005-08-19 at 16:03 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > On Fri, 2005-08-19 at 12:18 -0500, John A Meinel wrote:
> >
>
> > it's cached alright. I'm getting a read rate of about 150MB/sec. I
would
> > have thought
I need to improve the performance for the following
query.
Soon after I reboot my server, the following query takes
20 seconds the first time I run it.
When I run it after that, it takes approximately 2 seconds.
I understand the caching taking place (at the os or db
level, it doesn't matter here).
Ron wrote:
Oops. There's a misconception here. ... OTOH, access time is
_latency_, and that is not changed. Access time for a RAID set is equal
to that of the slowest access time, AKA highest latency, HD in the RAID
set.
You're overgeneralizing from one specific type of raid, aren't you
20 matches
Mail list logo
