Pavan Deolasee wrote: > IMHO we are making full circles here. We have already tried LP_DELETE > techniques > and moved away to simplify things. We also tried reusing dead space without > running PageRepairFragmentation. Each of these techniques worked just fine > with slightly different performance characteristics. What we now have is a > simplified algorithm which is much easier to follow and is safer, yet giving > us a very good performance boost. I am not sure if this is the right time to > throw new ideas because we would never be sure as what we are doing > would be the most optimal solution. Would it help if we go with some > solution right now, get rest of the review process done and then use > the feedback during beta testing to tune things ? We may have far more > data points at that time to choose one technique over other. And we > would also know what areas to focus on.
I totally understand. I was just throwing out ideas to make sure I fully understood it and to explore various options. I do agree we should just wait for the review, knowing we have these trade-offs. -- 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
