This is a discussion on Re: [pgsql-patches] Ctid chain following enhancement within the Pgsql Patches forums, part of the PostgreSQL category; --> 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 <tgl@sss.pgh.pa.us> ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 <tgl@sss.pgh.pa.us> 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 suggestion. > > Thanks, > Pavan > > -- > > EnterpriseDB http://www.enterprisedb.com [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate |
| |||
| Bruce Momjian <bruce@momjian.us> 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq |
| |||
| Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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. I only kept it for 8.4 because I was worried it might be needed for HOT performance. Are we sure that is not the case because that is why it was originally proposed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |
| |||
| Bruce Momjian <bruce@momjian.us> 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 worried it might be needed for HOT > performance. No such argument has been made in my hearing, and I can't imagine why either of the functions touched by the patch would be more performance-critical for HOT than they are today. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate |
| |||
| Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 worried it might be needed for HOT > > performance. > > No such argument has been made in my hearing, and I can't imagine why > either of the functions touched by the patch would be more > performance-critical for HOT than they are today. OK, removed from 8.4 queue. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |
| ||||
| On 6/2/07, Bruce Momjian <bruce@momjian.us> 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 |