Re: Review: Revise parallel pg_restore's scheduling heuristic - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Review: Revise parallel pg_restore's scheduling heuristic
Date
Msg-id 4A64530902000025000289B7@gw.wicourts.gov
Whole thread Raw
In response to Re: Review: Revise parallel pg_restore's scheduling heuristic  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

Previous
From: Laurent Laborde
Date:
Subject: Re: Higher TOAST compression.
Next
From: "Kevin Grittner"
Date:
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic