Re: Performance degrade running on multicore computer

Поиск
Список
Период
Сортировка
От afancy
Тема Re: Performance degrade running on multicore computer
Дата
Msg-id d9d086320911220102p4a2f4441wd66a1da828b98883@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance degrade running on multicore computer  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Hi,

I am using the PostgreSQL 8.4. What is the code path?   After a row is inserted to the table, it will update the fields of "validfrom", and "validto". Followings are the table structure, data, and the performance data:

xiliu=# \d page
              Table "pyetlexa.page"
     Column      |       Type        | Modifiers
-----------------+-------------------+-----------
 pageid          | integer           | not null
 url             | character varying |
 size            | integer           |
 validfrom       | date              |
 validto         | date              |
 version         | integer           |
 domainid        | integer           |
 serverversionid | integer           |
Indexes:
    "page_pkey" PRIMARY KEY, btree (pageid)
    "url_version_idx" btree (url, version DESC)

Here is the data in this table:
http://imagebin.ca/img/KyxMDIKq.png


Here is the performance data by "top":
http://imagebin.ca/img/2ssw4wEQ.png



Regards,

afancy

On Sun, Nov 22, 2009 at 12:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
afancy <groupme@gmail.com> writes:
> My PostgreSQL server has two CPUs (OS: Fedora 11), each with 4 cores. Total
> is 8cores.  Now I have several clients running at the same time to do insert
> and update on the same table, each client having its own connection.  I have
> made  two testing with  clients running in parallel to load 20M data in
> total. Each testing, the data is split evenly by the client number such that
> each client only loads a piece of data.

What exactly are you doing when you "load data"?  There are some code
paths that are slower if they have to examine not-yet-committed tuples,
and your report sounds a bit like that might be what's happening.
But with so few details (not even a Postgres version number :-()
it's difficult to be sure of anything.

                       regards, tom lane



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

Предыдущее
От: Sergey Aleynikov
Дата:
Сообщение: Re: sub-select makes query take too long - unusable
Следующее
От: Jonathan Blitz
Дата:
Сообщение: Why is the query not using the index for sorting?