scott.marlowe wrote:
> On Wed, 24 Mar 2004, pginfo wrote:
>
> > Hi,
> >
> > scott.marlowe wrote:
> >
> > > On Wed, 24 Mar 2004, pginfo wrote:
> > >
> > > > Hi,
> > > >
> > > > I am running pg 7.4.1 on linux box.
> > > > I have a midle size DB with many updates and after it I try to run
> > > > v
On Wed, 24 Mar 2004, pginfo wrote:
> Hi,
>
> scott.marlowe wrote:
>
> > On Wed, 24 Mar 2004, pginfo wrote:
> >
> > > Hi,
> > >
> > > I am running pg 7.4.1 on linux box.
> > > I have a midle size DB with many updates and after it I try to run
> > > vacuum full analyze.
> >
> > Is there a reason t
Hi,
scott.marlowe wrote:
> On Wed, 24 Mar 2004, pginfo wrote:
>
> > Hi,
> >
> > I am running pg 7.4.1 on linux box.
> > I have a midle size DB with many updates and after it I try to run
> > vacuum full analyze.
>
> Is there a reason to not use just regular vacuum / analyze (i.e. NOT
> full)?
>
> "SS" == Stalin Subbiah writes:
SS> We are looking into Sun V210 (2 x 1 GHz cpu, 2 gig ram, 5.8Os)
SS> vs. Dell 1750 (2 x 2.4 GHz xeon, 2 gig ram, RH3.0). database will
SS> mostly be write intensive and disks will be on raid 10. Wondering
SS> if 64bit 1 GHz to 32bit 2.4 GHz make a big differ
On Tuesday 23 March 2004 18:49, Woody Woodring wrote:
> Hello,
>
> I am using postgres 7.4.2 as a backend for geocode data for a mapping
> application. My question is why can't I get a consistent use of my indexes
> during a query, I tend to get a lot of seq scan results.
I'm not sure it wants to
Greg Spiegelberg wrote:
> > Will advise.
After creating 100, 1K, 10K, 100K and 1M-row subsets of account.cust and
the corresponding rows/tables with foreign key constraints referring to
the table, I'm unable to reproduce the behavior at issue.
explain analyze looks like the following, showing th
On Wed, 24 Mar 2004, pginfo wrote:
> Hi,
>
> I am running pg 7.4.1 on linux box.
> I have a midle size DB with many updates and after it I try to run
> vacuum full analyze.
Is there a reason to not use just regular vacuum / analyze (i.e. NOT
full)?
> It takes about 2 h.
Full vacuums, by the
Hi Bill,
I am vacuuming every 24 h.
I have a cron script about i.
But if I make massive update (for example it affects 1 M rows) and I start vacuum,
it take this 2 h.
Also I will note, that this massive update is running in one transaction ( I can
not update 100K and start vacuum after it).
regard
pginfo wrote:
Hi,
I am running pg 7.4.1 on linux box.
I have a midle size DB with many updates and after it I try to run
vacuum full analyze.
It takes about 2 h.
If I try to dump and reload the DB it take 20 min.
How can I improve the vacuum full analyze time?
How often are you vacuuming? If you'
I currently have it set up to vacuum/analyze every 2 hours. However my
QUERY PLAN #1 & #2 in my example I ran my explain immediately after a
vacuum/analyze.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joseph
Shraibman
Sent: Tuesday, March 23, 2004 2
> > Now if these vendors could somehow eliminate downtime due to human error
> > we'd be talking *serious* reliablity.
>
> You mean making the OS smart enough to know when clearing the arp
> cache is a bonehead operation, or just making the hardware smart
> enough to realise that the keyswitch real
Hi,
I am running pg 7.4.1 on linux box.
I have a midle size DB with many updates and after it I try to run
vacuum full analyze.
It takes about 2 h.
If I try to dump and reload the DB it take 20 min.
How can I improve the vacuum full analyze time?
My configuration:
shared_buffers = 15000
Darcy Buskermolen wrote:
-- Forwarded Message --
Subject: FreeBSD, PostgreSQL, semwait and sbwait!
Date: March 23, 2004 12:02 pm
From: "Jason Coene" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Hello all,
We're having a substantial problem with our FreeBSD 5.2 database server
ru
Josh Berkus wrote:
Forget hyperthreading. Look at their postgresql.conf settings. 8mb shared
mem, 16mb sort mem per connection for 512 connections, default
effective_cache_size.
Umm...its 64Mb shared buffers isn't it ?
However agree completely with general thrust of message partic
Josh Berkus wrote:
Mark,
It might be worth considering Apple if you want a 64-bit chip that has a
clock speed comparable to Intel's - the Xserv is similarly priced to Sun
V210 (both dual cpu 1U's).
Personally I'd stay *far* away from the XServs until Apple learns to build
some real ser
15 matches
Mail list logo
