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
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 |