On 21 Aug 2003 at 10:59, Andrew Sullivan wrote:
> On Wed, Aug 20, 2003 at 05:58:32PM -0400, Tom Lane wrote:
> > Jan Wieck <JanWieck@Yahoo.com> writes:
> > > the LRU chain but rather at it's end? This way a vacuum on a large table
> > > will not cause a complete cache eviction.
> >
> > I think what we really need is a way to schedule VACUUM's I/O at a lower
> > priority than normal I/Os. Wouldn't be very portable :-( ... but if the
>
> Hey, they both sounds like nifty ideas to me! The portability sure
> worries me, though, on that I/O trick. Still, Oracle (f'rinstance)
> made all kinds of optimisations for Sun (and conversely) partly
> because, I expect, that's where a lot of their users were, and the
> performance or reliability gains were significant. Whether that is
> worth doing for PostgreSQL, when there are probably lots of other
> targets to aim at, is an open question.
Well, if you guys remember my posts on performance recently, the said project
will probably drift to mysql as performance requirement on solaris platform
seems pretty steep to postgresql.
Personally I think inserting 5M rows in 11 column table should not take more
than an hour. ( That's the performance criteria). But apparently postgresql is
not making it no matter what..
Just an FYI, I think we need to do something for solaris. If a hourse does not
drink despite being taken to water, throw him in water.. After it's the
database users who are stuck. Not Sun..
Bye
Shridhar
--
Fun Facts, #14: In table tennis, whoever gets 21 points first wins. That's how
it once was in baseball -- whoever got 21 runs first won.
