Re: Review: Revise parallel pg_restore's scheduling heuristic

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Review: Revise parallel pg_restore's scheduling heuristic
Дата
Msg-id 4A64530902000025000289B7@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Review: Revise parallel pg_restore's scheduling heuristic  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> wrote:
> To performance test this properly you might need to devise a test
> that will use a sufficiently different order of queueing items to
> show the difference.
> 
> One thing I am particularly interested in is to see if queuing FK
> items for a table as soon as they become available, which is most
> likely to be when the referred to index is created, rather than
> possibly doing them all together (assuming they are named with the
> table name as a prefix) as TOC order would do, has a better
> performance or not.
Hmmm....  I'm reevaluating my database choice.  The 1.1TB database
does not have foreign key constraints as a matter of policy.  It is a
replica of the county databases, and we want to replicate whatever we
can of the county data -- failure for some reason of part of the data
to replicate should not block replication of something else, to
minimize differences.  Is there still value in using such a database
at all, or should I focus on databases in the 50GB to 90GB range with
FK constraints defined?
When you suggest devising a test to show a difference, in what way
would it be likely that I would need to modify the real-life database
to get such a test?  Our FKs do start with "<TableName>_".  We don't
have underscores in our table names, although we use similar naming
for our indexes.
-Kevin


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

Предыдущее
От: Laurent Laborde
Дата:
Сообщение: Re: Higher TOAST compression.
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Review: Revise parallel pg_restore's scheduling heuristic