Re: [PATCHES] HOT Patch - Ready for review

[Pavan Deolasee]

On 4/19/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:



What's the purpose of the HeapScanHintPagePrune mechanism in index
builds? I lost track of the discussion on create index, is the it
necessary for correctness?



Its not required strictly for correctness, but it helps us prune the
HOT-chains
while index building. During index build, if we skip a tuple which is
RECENTLY_DEAD, existing transactions can not use the index for queries.
Pruning the HOT-chains reduces the possibility of finding such tuples
while building the index.


A comment in IndexBuildHeapScan explaining

why it's done would be nice.



I would do that.


In any case a PG_TRY/CATCH block should be

used to make sure it's turned off after an unsuccessful index build.



Oh thanks. Would do that too

I would wait for other review comments before submitting a fresh patch.
I hope thats ok.

Thanks,
Pavan
--

EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT Patch - Ready for review

[Heikki Linnakangas]

Pavan Deolasee wrote:

Please find the attached HOT patch, which I think is now ready for
review.


What's the purpose of the HeapScanHintPagePrune mechanism in index 
builds? I lost track of the discussion on create index, is the it 
necessary for correctness? A comment in IndexBuildHeapScan explaining 
why it's done would be nice. In any case a PG_TRY/CATCH block should be 
used to make sure it's turned off after an unsuccessful index build.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(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] HOT Patch - Ready for review

[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.

---


Pavan Deolasee wrote:
 Please find the attached HOT patch, which I think is now ready for
 review.
 
 The only known issue left to-be-done  is making the index available
 in the read-committed transaction which created it. Right now the index
 is made available to the transaction unless  one or more rows were
 UPDATEd in the same transactions before creating the index OR there were
 RECENTLY_DEAD tuples that we did not index while building the index.
 Both of these cases do not seem very common to me.The patch can easily
 be tweaked to make the index available even in these cases, but I left it
 because Tom has raised concerns about transaction using the new index
 with some old snapshot. I haven't been able to create such a scenario
 so thought would best leave it until someone picks it up for review and
 take it up at that time.
 
 One of the regression test fails, but thats just a side-effect of how CIC
 works now. I didn't change the expected output just yet because that might
 have covered this side-effect. I plan to spend some time on performance
 testing and would post those results soon.
 
 I would appreciate if others also give it a shot and see if it gives any
 performance jump in their respective setups. I think the best would
 come out in IO bound testing.
 
 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 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