Re: Review: Revise parallel pg_restore's scheduling heuristic

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Date: 2009-07-20 16:20:41
Message-ID: 4A64530902000025000289B7@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-07-20 16:23:33 Re: Review: Revise parallel pg_restore's scheduling heuristic
Previous Message Laurent Laborde 2009-07-20 16:15:07 Re: Higher TOAST compression.