On Mon, 2007-03-19 at 14:33 +0530, Pavan Deolasee wrote:
Simon Riggs wrote:
We *must* make CREATE INDEX CONCURRENTLY work with HOT. The good news is
I think we can without significant difficulty.
Yeah, I think CREATE INDEX CONCURRENTLY is much easier to solve. Though
I am not
On Mon, 2007-03-19 at 09:28 +, Simon Riggs wrote:
On Mon, 2007-03-19 at 14:33 +0530, Pavan Deolasee wrote:
Simon Riggs wrote:
We *must* make CREATE INDEX CONCURRENTLY work with HOT. The good news is
I think we can without significant difficulty.
Yeah, I think CREATE
Simon Riggs wrote:
This problem is solved by moving the wait (for all transactions in
reference snapshot to finish) so that it is now between the first and
second scans, as described.
During the second Vscan we would prune each block, so the only remaining
tuple in the block when the
On Mon, 2007-03-19 at 16:06 +0530, Pavan Deolasee wrote:
Simon Riggs wrote:
This problem is solved by moving the wait (for all transactions in
reference snapshot to finish) so that it is now between the first and
second scans, as described.
During the second Vscan we would prune
Hannu Krosing wrote:
Ühel kenal päeval, E, 2007-03-19 kell 12:05, kirjutas Simon Riggs:
On Mon, 2007-03-19 at 10:51 +, Heikki Linnakangas wrote:
Pavan Deolasee wrote:
We've already used three of those, two for tracking HEAP_ONLY
and HOT_UPDATED tuples and one for tracking fragmented
On Mon, 2007-03-19 at 10:29 -0500, Merlin Moncure wrote:
On 3/17/07, Simon Riggs [EMAIL PROTECTED] wrote:
I'm very comfortable with the idea that HOT can be turned on/off for a
table. That gives us a workaround to bugs. Previously, changing things
like WITHOUT OIDS was done over two
On Sun, 2007-03-18 at 00:44 +0530, Pavan Deolasee wrote:
Simon Riggs wrote:
We need to be clear that we already have a solution to CREATE INDEX
CONCURRENTLY. Do you agree that we do? Does anyone see a problem with
the posted design for that?
If we have solved CREATE INDEX
