| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Paul A Vixie <vixie(at)mfnx(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: day 2 results |
| Date: | 2000-12-20 18:28:57 |
| Message-ID: | 5931.977336937@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Paul A Vixie <vixie(at)mfnx(dot)net> writes:
> the occasional 1.2sec has got to be due to some kind of scheduling or I/O
> irregularity.
Hmm, could it just be delay when your syncer process runs? Under WAL,
I believe we don't fsync anything except the WAL log file, so a bulk
insert operation would probably create lots and lots of dirty kernel
buffers that syncer would decide to shove out to disk every 30 sec or
so. Is there any way to correlate the timing spikes against syncer
activity?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2000-12-20 18:44:35 | Re: performance modality in 7.1 for large text attributes? |
| Previous Message | Thomas Lockhart | 2000-12-20 18:18:01 | Re: Re: Generating HISTORY file |