Jim C. Nasby wrote:
On Mon, Mar 19, 2007 at 12:05:19PM +, Simon Riggs wrote:
I was unwilling to compromise to have HOT if only one index existed, but
IMHO allowing HOT with <= 3 indexes is an acceptable compromise for this
release. (We can always use vertical partitioning techniques to al
On Mon, Mar 19, 2007 at 12:05:19PM +, Simon Riggs wrote:
> I was unwilling to compromise to have HOT if only one index existed, but
> IMHO allowing HOT with <= 3 indexes is an acceptable compromise for this
> release. (We can always use vertical partitioning techniques to allow
> additional acc
On 3/19/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
Yeah, I think CREATE INDEX CONCURRENTLY is much easier to solve. Though
I am not completely convinced that we can do that without much changes
to CREATE INDEX CONCURRENTLY logic. For example, I believe we still
need to lock out HOT-updates bef
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 releases, so I'd suggest the same
thing here. Add the option now, di
Ü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:
> > > Heikki Linnakangas wrote:
> > > > Pavan Deolasee wrote:
> > > > We would only need the extra byte in HOT-updated tuples.
> > > Alterna
On Mon, 2007-03-19 at 10:51 +, Heikki Linnakangas wrote:
> Pavan Deolasee wrote:
> > Heikki Linnakangas wrote:
> > > Pavan Deolasee wrote:
> > > We would only need the extra byte in HOT-updated tuples.
> > Alternatively, we could use the bits we have free in infomask2. There's
> > currently
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 completely convinced that we can do that without much changes
to CR
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?
>
> Hopefully it is only CREATE INDEX that we need to think about.
>
I agree. Lets first decide whether
On Sat, 2007-03-17 at 23:11 +0530, Pavan Deolasee wrote:
> The algorithm would look like:
>
> 1. Disable HOT-updates
The lock held by CREATE INDEX already prevents HOT updates. So steps 1
and 8 aren't needed.
We need to be clear that we already have a solution to CREATE INDEX
CONCURRENTLY. Do y
Simon Riggs wrote:
>
> As a result of the issues, I think Pavan is playing safe, to make sure
> there is *an* option, so that we can build upwards from there. The
> proposal is pragmatism only, while we discuss other approaches.
>
Absolutely true. I agree that CHILLing the table with AccessExclus
On Sat, 2007-03-17 at 11:45 -0400, Tom Lane wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > While creating an index, if a HEAP_ONLY tuple is found,
> > CREATE INDEX [CONCURRENTLY] fails with an error and the
> > user needs to SET HOT OFF and then try again. While turning
> > HOT off, the
On Sat, 2007-03-17 at 12:43 +0530, Pavan Deolasee wrote:
> How do we move forward with the CREATE INDEX issue with
> HOT ? There are quite a few suggestions and objections.
> Can we please discuss and decide on the plan ? I am very
> comfortable with the current state of HOT, the results
> are enco
12 matches
Mail list logo
