Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Pavan Deolasee
On 6/2/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: OK, removed from 8.4 queue. I am OK with this, though I personally never felt that it complicated the code :-) Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I think it should be dropped entirely. The argument against was that > >> it complicated the code in a non-performance-critical path, and that > >> argument isn't going to be different next time. > > > I only kep

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Bruce Momjian
Patch rejected, not held for 8.4, because it uglifies the code. --- Pavan Deolasee wrote: > On 1/28/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > > > OTOH it might be > > cleaner to refactor things that way, if we were going t

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I think it should be dropped entirely. The argument against was that >> it complicated the code in a non-performance-critical path, and that >> argument isn't going to be different next time. > I only kept it for 8.4 because I was wor

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > This has been saved for the 8.4 release: > > I think it should be dropped entirely. The argument against was that > it complicated the code in a non-performance-critical path, and that > argument isn't going to be different next time

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > This has been saved for the 8.4 release: I think it should be dropped entirely. The argument against was that it complicated the code in a non-performance-critical path, and that argument isn't going to be different next time. r

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Bruce Momjian
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Pavan Deolasee wrote: > On 1/28/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > > > OTOH it might be > > cleaner to refac

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-05-30 Thread Zdenek Kotala
Pavan Deolasee napsal(a): On 5/29/07, *Zdenek Kotala* <[EMAIL PROTECTED] > wrote: I'm looking on your patch. I have one comment: If you have old tid and new tid you can easy compare if new tid points to different page? And if page is still same there is

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-05-30 Thread Pavan Deolasee
On 5/29/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote: I'm looking on your patch. I have one comment: If you have old tid and new tid you can easy compare if new tid points to different page? And if page is still same there is no reason to Unlock it and lock again. I think add inner loop somethi

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-05-29 Thread Zdenek Kotala
Pavan Deolasee wrote: On 1/28/07, *Tom Lane* <[EMAIL PROTECTED] > wrote: OTOH it might be cleaner to refactor things that way, if we were going to apply this. Here is a revised patch which includes refactoring of heap_get_latest_tid(), as per Tom's suggesti

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-02-20 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Pa