| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: slow commits with heavy temp table usage in 8.4.0 |
| Date: | 2009-08-05 20:02:17 |
| Message-ID: | 28632.1249502537@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Todd A. Cook" <tcook(at)blackducksoftware(dot)com> writes:
> I've noticed that on 8.4.0, commits can take a long time when a temp table is repeatedly
> filled and truncated within a loop. A very contrived example is
Hmm. I tweaked the function to allow varying the number of truncates:
regression=# begin;
BEGIN
Time: 1.037 ms
regression=# select commit_test_with_truncations(10000) ;
commit_test_with_truncations
------------------------------
(1 row)
Time: 9466.060 ms
regression=# commit;
COMMIT
Time: 1095.946 ms
regression=# begin;
BEGIN
Time: 1.002 ms
regression=# select commit_test_with_truncations(30000) ;
commit_test_with_truncations
------------------------------
(1 row)
Time: 93492.874 ms
regression=# commit;
COMMIT
Time: 3184.248 ms
The commit time doesn't seem tremendously out of line, but it looks
like there's something O(N^2)-ish in the function execution. Do
you see a similar pattern? With so many temp files there could well
be some blame on the kernel side. (This is a Fedora 10 box.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2009-08-05 20:04:49 | Re: GRANT ON ALL IN schema |
| Previous Message | Robert Haas | 2009-08-05 19:51:24 | Re: GRANT ON ALL IN schema |