On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > Please see the version 14 of HOT patch attached.
>
> I expected to find either a large new README, or some pretty substantial
> additions to existing README files, to document how this all works.
>
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>> Please see the version 14 of HOT patch attached.
>
> I expected to find either a large new README, or some pretty substantial
> additions to existing README files, to document how this all works.
> The commen
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>>> Please see the version 14 of HOT patch attached.
>>
>> I expected to find either a large new README, or some pretty substantial
>> additions to existing READM
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> You are right - a new index might mean that an existing HOT chain
> is broken as far as the new index is concerned. The way we address
> that is by indexing the root tuple of the chain, but the index key is
> extracted from the last tuple in the chain.
I wanted to push to see if I made a version of this patch against CVS
head if we could see it included in 8.3.
It's of clear value for people who use pg_dump and tablespaces. HOT
and tsearch development still continues and implementations of each
feature are still being discussed/debated as of th
Gavin M. Roy wrote:
> I wanted to push to see if I made a version of this patch against CVS
> head if we could see it included in 8.3.
>
> It's of clear value for people who use pg_dump and tablespaces. HOT
> and tsearch development still continues and implementations of each
> feature are still
On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > You are right - a new index might mean that an existing HOT chain
> > is broken as far as the new index is concerned. The way we address
> > that is by indexing the root tuple of the chain, but the
Bruce Momjian wrote:
If you want it in 8.3 you are going to need some community members to
take ownership of the patch, take responsibility for it, testing it, etc,
and argue that a feature addition that arrived in July should be added.
Not impossible, but you are going to need advocates for th
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > If you want it in 8.3 you are going to need some community members to
> > take ownership of the patch, take responsibility for it, testing it, etc,
> > and argue that a feature addition that arrived in July should be added.
> > Not impossible,
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
If you want it in 8.3 you are going to need some community members to
take ownership of the patch, take responsibility for it, testing it, etc,
and argue that a feature addition that arrived in July should be added.
Not i
Andrew Dunstan wrote:
> >> At this stage we should be kicking things out of the list, not adding to
> >> it, IMNSHO. It really doesn't look to me like HOT is ready, from what I
> >> can see of the discussion, and desirable as it is I think it should
> >> probably wait.
> >>
> >
> > Are you
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> At this stage we should be kicking things out of the list, not adding to
>
> >> HOT too unless there is a short clear path
> >> to committal (which seems unlikely g
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I don't think that works --- what if the last tuple in the chain isn't
>> committed good yet? If its inserter ultimately rolls back, you've
>> indexed the wrong value.
> I am confused. How could we g
"Tom Lane" <[EMAIL PROTECTED]> writes:
>>> Isn't the extra machination for C.I.C. just useless complication?
>>> What's the point of avoiding creation of new broken HOT chains when
>>> you still have to deal with existing ones?
>
>> IMHO the extra step in C.I.C simplifies the index build.
>
> If y
Gregory Stark <[EMAIL PROTECTED]> writes:
>> If you make the change suggested above, I think you don't need to do
>> things differently in C.I.C.
> It seems to me if you wait out transactions as you come across them you could
> end up waiting a whole lot longer than the way it works now where it w
Tom Lane escribió:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> I don't think that works --- what if the last tuple in the chain isn't
> >> committed good yet? If its inserter ultimately rolls back, you've
> >> indexed the wrong value.
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> Not if someone else releases lock before committing.
> FWIW, a red flag raised for me here, though maybe it is irrelevant or
> unimportant. Currently, VACUUM acquires an exclusive lock for
> truncating the table. The lock is kept
On 8/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>
> Not if someone else releases lock before committing. Which I remind you
> is a programming technique we use quite a lot with respect to the system
> catalogs. I'm not prepared to guarantee that th
18 matches
Mail list logo
