| From: | Marti Raudsepp <marti(at)juffo(dot)org> |
|---|---|
| To: | Robert Klemme <shortcutter(at)googlemail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Postgres for a "data warehouse", 5-10 TB |
| Date: | 2011-09-13 18:11:31 |
| Message-ID: | CABRT9RAKjmoa91sOBySx97=0ZKv64sD7miY0ZgUDu9dK0rQygw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Sep 13, 2011 at 19:34, Robert Klemme <shortcutter(at)googlemail(dot)com> wrote:
> I don't think so. You only need to catch the error (see attachment).
> Or does this create a sub transaction?
Yes, every BEGIN/EXCEPTION block creates a subtransaction -- like a
SAVEPOINT it can roll back to in case of an error.
> Yes, I mentioned the speed issue. But regardless of the solution for
> MySQL's "INSERT..ON DUPLICATE KEY UPDATE" which Igor mentioned you
> will have the locking problem anyhow if you plan to insert
> concurrently into the same table and be robust.
In a mass-loading application you can often divide the work between
threads in a manner that doesn't cause conflicts.
For example, if the unique key is foobar_id and you have 4 threads,
thread 0 will handle rows where (foobar_id%4)=0, thread 1 takes
(foobar_id%4)=1 etc. Or potentially hash foobar_id before dividing the
work.
I already suggested this in my original post.
Regards,
Marti
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igor Chudov | 2011-09-13 18:38:32 | Re: Postgres for a "data warehouse", 5-10 TB |
| Previous Message | Marc Mamin | 2011-09-13 17:54:19 | Re: Postgres for a "data warehouse", 5-10 TB |