On Wed, May 30, 2012 at 4:16 PM, Sergey Koposov <kopo...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
