| From: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: slow commits with heavy temp table usage in 8.4.0 |
| Date: | 2009-08-09 11:09:26 |
| Message-ID: | 4A7EAE66.9060601@mansionfamily.plus.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> the function time and the commit time a lot better. But I'm not sure
> if the use-case is popular enough to deserve such a hack.
>
>
For some OLTP workloads, it makes a lot of sense to spool tuples of
primary key plus new fields into a temp table and then doing a single update
or delete operation referencing the temp table. Perhaps not so much
for code designed for postgres where there is some extra flexibility
with array params and the like, but for code that targets other systems
as well.
Having temp tables be as fast as possible is quite a big win in this case.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-08-09 12:23:39 | Re: revised hstore patch |
| Previous Message | Simon Riggs | 2009-08-09 10:11:11 | Re: hot standby - merged up to CVS HEAD |