On Thu, Dec 2, 2010 at 6:37 PM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
