Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
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 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] 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
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
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. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
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 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
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
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 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] 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
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
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 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 [EMAIL PROTECTED] 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
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
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
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 something like: Tom has already expressed his unwillingness to add complexity without any proven benefits. Your suggestion though good would make the code more unreadable without much benefit since the function is not called very often. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
Pavan Deolasee napsal(a): On 5/29/07, *Zdenek Kotala* [EMAIL PROTECTED] mailto:[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 something like: Tom has already expressed his unwillingness to add complexity without any proven benefits. Your suggestion though good would make the code more unreadable without much benefit since the function is not called very often. OK. I think Bruce can remove your patch from pipeline? Zdenek ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
Pavan Deolasee wrote:
On 1/28/07, *Tom Lane* [EMAIL PROTECTED] mailto:[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 suggestion.
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 something like:
Readbufer
Lock
do{
...
} while(ctid.block_id == tid.block_id)
ReleaseAndUnlock
can save some extra locking/unlocking cycle. What do you think?
Zdenek
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement
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. --- 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 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
