Re: Parallel pg_restore versus old dump files

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Igor Neyman <ineyman(at)perceptron(dot)com>
Subject: Re: Parallel pg_restore versus old dump files
Date: 2010-06-23 01:47:03
Message-ID: 4C216797.7020100@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>>> Another possibility is to just remove the inside-the-loop error test
>>> altogether: make it just skip till it finds the desired item, and only
>>> throw an error if it hits EOF without finding it. In the case that
>>> the error test is trying to catch, this would mean significantly more
>>> work done before reporting the error, but do we really care? I'm
>>> leaning to this solution because it would not require exporting state
>>> from the parallel restore control logic.
>>>

>> Would exporting a bit of state be so bad?
>>
>
> The threaded case seems a bit messy, and frankly I don't believe that
> we'd be buying anything. The error case never actually occurs in the real
> world, except perhaps on corrupted archive files, so why should we care
> about performance for it?
>
>

OK, I can buy that.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Francis Markham 2010-06-23 02:12:37 Implementation of Date/Time Input Interpretation
Previous Message Tom Lane 2010-06-23 01:26:47 Re: Parallel pg_restore versus old dump files