Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Дата
Msg-id CAMkU=1z2GDbWoALm7Rh5t9pauq1dvyeou+FQ0xnoNq9UTXUSaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Sergey Koposov <koposov@ast.cam.ac.uk>)
Ответы Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Sergey Koposov <koposov@ast.cam.ac.uk>)
Список pgsql-hackers
On Wed, May 30, 2012 at 4:16 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote:

> But the question now is whether there is a *PG* problem here or not, or is
> it Intel's or Linux's problem ? Because still the slowdown was caused by
> locking. If there wouldn't be locking there wouldn't be any problems (as
> demonstrated a while ago by just cat'ting the files in multiple threads).

You cannot have a traditional RDBMS without locking.  From your
description of the problem, I probably wouldn't be using a traditional
database system at all for this, but rather flat files and Perl.  Or
at least, I would partition the data before loading it to the DB,
rather than trying to do it after.

But anyway, is idt_match a fairly static table?  If so, I'd partition
that into 16 tables, and then have each one of your tasks join against
a different one of those tables.  That should relieve the contention
on the index root block, and might have some other benefits as well.

Cheers,

Jeff


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergey Koposov
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile