"Tom Lane" <[EMAIL PROTECTED]> writes: > AFAICS, the whole indcreatexid and validForTxn business is a waste of > code. By the time CREATE INDEX CONCURRENTLY is ready to set indisvalid, > surely any transactions that could see the broken HOT chains are gone. > There might have been some reason for this contraption before we had > plan invalidation, but what use is it now?
It sounds like you're missing one of the big problems HOT ran into. When you create a new index your new index could include columns which were previously not covered in any index. So there could be pre-existing HOT chains which would no longer be eligible for HOT treatment. The README called such chains "broken HOT chains" and has some more information about them. Nobody who can see any old tuples in such chains can risk using your new index since the chain will be indexed under the "wrong" key. *New* transactions can use the index however since they'll only see the head of the chain which is the key the chain is indexed under. It's the old transactions which can see the old key values which aren't included in the index. Or do you see some other reason that plan invalidation can solve this problem? We looked for and tried a lot of different approaches to solve this problem. This was the lowest impact solution and the only one that was convincingly correct (imho). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
