On Tue, Apr 05, 2005 at 01:56:05PM -0400, Ian Westmacott wrote:
> > And if UFS is available for linux you should might try it.
>
> Would UFS help the fragmentation issue? We have seen ext3
> allocating blocks in 2-4 pages, while XFS manages 8-16
> pages.
Actually, I spoke too soon in my last rep
On Tue, Apr 05, 2005 at 01:56:05PM -0400, Ian Westmacott wrote:
> > And if UFS is available for linux you should might try it.
>
> Would UFS help the fragmentation issue? We have seen ext3
> allocating blocks in 2-4 pages, while XFS manages 8-16
> pages.
Hrm... I'm not sure what the allocation s
Ian Westmacott <[EMAIL PROTECTED]> writes:
> On Tue, 2005-04-05 at 11:34, Tom Lane wrote:
>> Have you looked at whether you can slow down the rate of XID consumption
>> (ie, by bundling operations into larger transactions)? That might be a
>> more useful route to limiting the costs involved.
> Ye
On Tue, 2005-04-05 at 11:39, Jim C. Nasby wrote:
> On Tue, Apr 05, 2005 at 11:13:06AM -0400, Ian Westmacott wrote:
> > On Tue, 2005-04-05 at 00:41, Jim C. Nasby wrote:
> > > We'll only answer if you do a write-up on your database. :P
> > >
> > > Seriously, those are some seriously big numbers. Wha
On Tue, 2005-04-05 at 11:34, Tom Lane wrote:
> Ian Westmacott <[EMAIL PROTECTED]> writes:
> > But the question is whether vacuum freezing tables will
> > help me reduce the frequency of a full vacuum, or reduce
> > its cost when we do it? That is, if more transactions
> > are frozen, will a full v
On Tue, Apr 05, 2005 at 11:13:06AM -0400, Ian Westmacott wrote:
> On Tue, 2005-04-05 at 00:41, Jim C. Nasby wrote:
> > We'll only answer if you do a write-up on your database. :P
> >
> > Seriously, those are some seriously big numbers. What else is the
> > database doing? What hardware is it runni
Ian Westmacott <[EMAIL PROTECTED]> writes:
> But the question is whether vacuum freezing tables will
> help me reduce the frequency of a full vacuum, or reduce
> its cost when we do it? That is, if more transactions
> are frozen, will a full vacuum be more efficient
> (primarily in the I/O)?
I'm
On Tue, 2005-04-05 at 02:42, Tom Lane wrote:
> "Ian Westmacott" <[EMAIL PROTECTED]> writes:
> > The problem is that we are writing rows every 1/15 second, 24x7. There
> > is no down time. I'm wondering if there is any way to avoid vacuuming
> > the old tables over and over. The documentation see
On Tue, 2005-04-05 at 00:41, Jim C. Nasby wrote:
> We'll only answer if you do a write-up on your database. :P
>
> Seriously, those are some seriously big numbers. What else is the
> database doing? What hardware is it running on?
We run on a dual 3.2GHz P4 with 2GB RAM, but are still
finalizing
"Ian Westmacott" <[EMAIL PROTECTED]> writes:
> The problem is that we are writing rows every 1/15 second, 24x7. There
> is no down time. I'm wondering if there is any way to avoid vacuuming
> the old tables over and over. The documentation seems to indicate that
> a full vacuum is needed to avoi
We'll only answer if you do a write-up on your database. :P
Seriously, those are some seriously big numbers. What else is the
database doing? What hardware is it running on?
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.
I have a near-real-time system writing into a Postgres 7.4.2 database
on the order of 340 million rows per day in about 300 million
transactions. So we quickly bump up against the XID wrap-around
issue. To address this, we divide the tables into 24-hour periods.
Once we roll over to a new period,
12 matches
Mail list logo
