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 по дате отправления: