Re: [PERFORM] pg_dump and thousands of schemas

От: Tom Lane
Тема: Re: [PERFORM] pg_dump and thousands of schemas
Дата: ,
Msg-id: 26886.1338437897@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: [PERFORM] pg_dump and thousands of schemas  (Stephen Frost)
Список: pgsql-hackers

Скрыть дерево обсуждения

Re: [PERFORM] pg_dump and thousands of schemas  (Tatsuo Ishii, )
 Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane, )
  Re: [PERFORM] pg_dump and thousands of schemas  (Stephen Frost, )
   Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane, )
  Re: [PERFORM] pg_dump and thousands of schemas  (Tatsuo Ishii, )
 Re: [PERFORM] pg_dump and thousands of schemas  (Bruce Momjian, )
  Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane, )
   Re: [PERFORM] pg_dump and thousands of schemas  (Bruce Momjian, )
   Re: [PERFORM] pg_dump and thousands of schemas  (Robert Haas, )
    Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane, )
     Re: [PERFORM] pg_dump and thousands of schemas  (Jeff Janes, )
      Re: [PERFORM] pg_dump and thousands of schemas  (Robert Haas, )

Stephen Frost <> writes:
> The current situation where the client-to-server latency accounts for
> multiple minutes of time is just ridiculous, however, so I feel we need
> some form of this patch, even if the server side is magically made much
> faster.  The constant back-and-forth isn't cheap.

No, you're missing my point.  I don't believe that client-to-server
latency, or any other O(N) cost, has anything to do with the problem
here.  The problem, as Jeff has demonstrated, is the O(N^2) costs
associated with management of the local lock table.  It is utterly
pointless to worry about O(N) costs until that's fixed; and it's just
wrong to claim that you've created a significant speedup by eliminating
a constant factor when all you've done is staved off occurrences of the
O(N^2) problem.

Once we've gotten rid of the local lock table problem, we can re-measure
and see what the true benefit of this patch is.  I'm of the opinion
that it will be in the noise compared to the overall runtime of pg_dump.
I could be wrong, but you won't convince me of that with measurements
taken while the local lock table problem is still there.

            regards, tom lane


В списке pgsql-hackers по дате сообщения:

От: Heikki Linnakangas
Дата:
Сообщение: Re: GiST buffering build, bug in levelStep calculation
От: Simon Riggs
Дата:
Сообщение: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)