"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> I'm departing in three ways from the simple IDE
> model that (I presume) the default random page cost of 4 is based on- The
> disks are SCSI & RAID and the FS would be different.
Actually, the default 4 is based on experiments I did quite awhile back
> ...About one year ago I considered moving to a journaling file system, but
> opted not to because it seems like that's what WAL does for us already. How
> does putting a journaling file system under it add more reliability?
WAL only works if the WAL files are actually written to disk and can be
Nick,
> ...About one year ago I considered moving to a journaling file system, but
> opted not to because it seems like that's what WAL does for us already. How
> does putting a journaling file system under it add more reliability?
It lets you restart your server quickly after an unexpected power
I'm confused:
Ang Chin Han wrote:
> We've been using ext3fs for our production systems. (Red Hat Advanced
> Server 2.1)
Vincent van Leeuwen wrote:
> I'd upgrade to a journaling filesystem as soon as possible for
> reliability.
...About one year ago I considered moving to a journaling file syst
On Fri, 18 Jul 2003, Tom Lane wrote:
> >> Adjusting the cpu_tuple_cost to 0.042 got the planner to choose the index.
>
> > Doesn't sound very good and it will most likely make other queries slower.
>
> Seems like a reasonable approach to me --- certainly better than setting
> random_page_cost to
The Types of the join columns were different text vs varchar(100),
now its working fine and using a Hash Join
Thanks once again.
regds
mallah.
explain analyze select b.state,a.city from data_bank.updated_profiles a
join public.city_master b using(city) where source='BRANDING' and
a.state
>> > Be sure to mount noatime
>>
>> I did "chattr -R +A /var/lib/pgsql/data"
>> that should do the trick as well or am I wrong?
>>
>
> According to the man page it gives the same effect.
> There are a few things you should consider though:
> - new files won't be created with the same options (I
On 2003-07-18 18:20:55 +0200, Oliver Scheit wrote:
> > Be sure to mount noatime
>
> I did "chattr -R +A /var/lib/pgsql/data"
> that should do the trick as well or am I wrong?
>
According to the man page it gives the same effect. There are a few things you
should consider though:
- new files won
> Be sure to mount noatime
I did "chattr -R +A /var/lib/pgsql/data"
that should do the trick as well or am I wrong?
regards,
Oli
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Fri, 18 Jul 2003, Rajesh Kumar Mallah wrote:
> Hi All,
>
> data_bank.updated_profiles and public.city_master are small tables
> with 21790 and 49303 records repectively. both have indexes on the join
> column. in first one on (city,source) and in second one on (city)
>
> The query below does no
On 2003-07-17 10:41:35 -0500, Nick Fankhauser wrote:
> I'm using ext2. For now, I'll leave this and the OS version alone. If I
>
I'd upgrade to a journaling filesystem as soon as possible for reliability.
Testing in our own environment has shown that PostgreSQL performs best on ext3
(yes, better
On Fri, 18 Jul 2003, Ang Chin Han wrote:
> Shridhar Daithankar wrote:
> > On 17 Jul 2003 at 10:41, Nick Fankhauser wrote:
> >
> >>I'm using ext2. For now, I'll leave this and the OS version alone. If I
> >
> >
> > I appreciate your approach but it almost proven that ext2 is not the best and
>
Thanks for the suggestions in the FS types- especially the Debian oriented
info. I'll start by playing with the memory allocation parameters that I
originally listed (seems like they should provide results in a way that is
unaffected by the disk IO). Then once I have them at optimal values, move o
On Fri, 18 Jul 2003, Tom Lane wrote:
> =?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <[EMAIL PROTECTED]> writes:
> > On Fri, 18 Jul 2003, Fabian Kreitner wrote:
> >> Adjusting the cpu_tuple_cost to 0.042 got the planner to choose the index.
>
> > Doesn't sound very good and it will most likely make other q
Martin Foster <[EMAIL PROTECTED]> writes:
> My question is, should the purging of rows be done more often then once
> a day for both tables. Is this why performance seems to take a hit
> specifically?
Given that the hourly purge seems to work well for you, I'd suggest
trying it on both tables.
> > >Adam Witney wrote:
> [snip]
> > If you would go with that one, make sure to get the optional BBWC
> > (Battery Backed Write Cache). Without it the controller
> won't enable
> > the write-back cache (which it really shouldn't, since it
> wouldn't be
> > safe without the batteries). WB cach
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <[EMAIL PROTECTED]> writes:
> On Fri, 18 Jul 2003, Fabian Kreitner wrote:
>> Adjusting the cpu_tuple_cost to 0.042 got the planner to choose the index.
> Doesn't sound very good and it will most likely make other queries slower.
Seems like a reasonable approach
Hi All,
data_bank.updated_profiles and public.city_master are small tables
with 21790 and 49303 records repectively. both have indexes on the join
column. in first one on (city,source) and in second one on (city)
The query below does not return for long durations > 10 mins.
explain analyze s
On Fri, Jul 18, 2003 at 12:55:12AM -0600, Martin Foster wrote:
> The other table follows a sequential order and carries more columns of
> information. However, this table clears it's entry nightly and with
> current settings will delete roughly a days traffic sitting at 50K rows
> of information.
On Thu, 2003-07-17 at 13:55, Magnus Hagander wrote:
> >Adam Witney wrote:
[snip]
> If you would go with that one, make sure to get the optional BBWC
> (Battery Backed Write Cache). Without it the controller won't enable the
> write-back cache (which it really shouldn't, since it wouldn't be safe
>
On Wed, 2003-07-16 at 23:25, Roman Fail wrote:
[snip]
> has every bit of redundancy you can order. While uncommon, the
> backplane is one one of the many single points of failure!
Unless you go with a shared-disk cluster (Oracle 9iRAC or OpenVMS)
or replication.
Face it, if your pockets are dee
On 18/07/2003 07:55 Martin Foster wrote:
[snip]
A VACUUM FULL will correct the issue, but put the site out of commission
for roughly 20 minutes as the drive crunches the information.
My question is, should the purging of rows be done more often then once
a day for both tables. Is this why perform
Shridhar Daithankar wrote:
On 17 Jul 2003 at 10:41, Nick Fankhauser wrote:
I'm using ext2. For now, I'll leave this and the OS version alone. If I
I appreciate your approach but it almost proven that ext2 is not the best and
fastest out there.
Agreed.
IMO, you can safely change that to reiserf
23 matches
Mail list logo
