Jack Orenstein <[EMAIL PROTECTED]> writes:
> I'm looking at one case in which two successive transactions, each
> updating a handful of records, take 26 and 18 *seconds* (not msec) to
> complete. These transactions normally complete in under 30 msec.
I've seen installations in which it seemed that
Jack Orenstein wrote:
> Bruce Momjian wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >>4. I understand that a "background writer" is being contemplated for
> >>7.5. Will that replace or augment the checkpoint process? Any
> >>comments on how that work will apply to my problem would be
> >>appreciated
Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
4. I understand that a "background writer" is being contemplated for
7.5. Will that replace or augment the checkpoint process? Any
comments on how that work will apply to my problem would be
appreciated. I wouldn't mind seeing the average performance
Sorry about that, I meant kbytes, not megs. My point being it's NOT
measured in 8k blocks, like a lot of other settings. sorry for the mixup.
On Fri, 7 May 2004, Bricklen wrote:
> scott.marlowe wrote:
> > sort_mem might do with a small bump, especially if you're only handling a
> > few connec
On Mon, 10 May 2004, Anderson Boechat Lopes wrote:
> Hum... now i think i´m beginning to understand.
>
> The vacuum analyse is recommended to perform at least every day, after
> adding or deleting a large number of records, and not vacuum full analyse.
> I´ve performed the vacuum full ana
scott.marlowe wrote:
sort_mem might do with a small bump, especially if you're only handling a
few connections at a time. Be careful, it's per sort, and measured in
megs, so it's easy for folks to set it too high and make their machine
start flushing too much kernel cache, which will slow down
[EMAIL PROTECTED] ("Anderson Boechat Lopes") writes:
> I´m new here and i´m not sure if this is the right email to
> solve my problem.
This should be OK...
> Well, i have a very large database, with vary tables and very
> registers. Every day, too many operations are perfomed in that DB,
[EMAIL PROTECTED] wrote:
> 4. I understand that a "background writer" is being contemplated for
> 7.5. Will that replace or augment the checkpoint process? Any
> comments on how that work will apply to my problem would be
> appreciated. I wouldn't mind seeing the average performance,
> (without t
My company is developing a PostgreSQL application. We're using 7.3.4
but will soon upgrade to 7.4.x. Our OS is RedHat 9. Our production
machines have 512 MB RAM and IDE disks. So far we've been using
default configuration settings, but I have started to examine
performance and to modify these sett
Hum... now i think i´m beginning to understand.
The vacuum analyse is recommended to perform at least every day, after
adding or deleting a large number of records, and not vacuum full analyse.
I´ve performed the vacuum full analyse every day and after some time i´ve
noticed the database w
Well, i have a very large database, with vary tables and very
registers. Every day, too many operations are perfomed in that DB, with
queries that insert, delete and update. Once a week some statistics are
collected using vacuum analyze.
Have vacuum analyze running once an HOUR if it's very
Anderson Boechat Lopes wrote:
Hi.
I´m new here and i´m not sure if this is the right email to solve my
problem.
Well, i have a very large database, with vary tables and very
registers. Every day, too many operations are perfomed in that DB, with
queries that insert, delete and up
Hi.
I´m new here and
i´m not sure if this is the right email to solve my problem.
Well, i have a
very large database, with vary tables and very registers. Every day, too
many operations are perfomed in that DB, with queries that insert, delete and
update. Once a week some sta
13 matches
Mail list logo
