On Thu, Dec 2, 2010 at 6:37 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> It seems to me that a COPY command executed in a transaction with no
>> other open snapshots writing to a table created or truncated within
>> the same transaction should be able to write frozen tuples from the
>> get-go, regardless of anything else we do.
>
> Well, some transaction might pick up a snapshot between the time you
> begin the copy and the time it commits. We'd need to prevent such a
> transaction from actually reading the table.
Oh, hmm. That's awkward. I guess under present semantics it can see
the table - but not its contents - once the inserting transaction has
committed. That stinks.
>> I don't think it would be appropriate to hold off
>> making the visibility map crash-safe, on the off chance that our
>> design for so doing might complicate something else we want to do
>> later.
>
> I'm not suggesting we hold off on it at all. To the contrary, I'm
> suggesting that we simply log updates of PD_ALL_VISIBLE as well as VM
> bits, at least until a performance problem presents itself. That will
> _simplify_ the design.
>
> Then, when a performance problem does present itself for a certain use
> case, we can see how to fix it. If many cases are affected, then we
> might choose one of these more creative solutions that breaks the rules
> in controlled ways, understanding the trade-offs. If only bulk loading
> is affected, we might choose to address that case directly.
I don't think that you can seriously suggest that emitting that volume
of FPIs isn't going to be a problem immediately. We have to have some
solution to that problem out of the gate.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company