Forum OpenACS Development: Re: acs_object__new slowness...

Collapse
Posted by Don Baccus on
Actually I was thinking of changing *all* first-level keys to use the object's object_id, though that's not what I said :)  Changing to this scheme would fix the null context_id problem automatically, that's what I'm thinking.

So your A,B,C nodes would all have their object_id as their first-level sortkey ...

Now doing the update may still be difficult because update's in PG aren't (logically) atomic so you can have unique constraint errors generated mid-update so any update script has to be very careful, I don't think you can just do one big UPDATE statement.

But this is the most attractive solution I've been able to think of ...

Collapse
Posted by Jeff Davis on
I think I could write a script that would build the new tree sortkeys in 2 or 3 statements and flop them in without a problem. (basically you pull the current ones out and renumber in a tmp table, set all the current ones to the id, then update the ones with context_id not null which should be robust, reasonably fast, and not at all difficult). Oh, drop the triggers first as well...

I suppose I should write a TIP for it since it should be approved (and I am not sure if people want this to go in for 5.0 or not). It does make a big difference difference (and is essential for anything openacs.org size or bigger) and I don't think the code or the upgrades are at all difficult but I know people want 5.0 to ship as well.

Btw, do table locks in plpgsql have the same problem as select for update?