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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
