IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New You have ...
..."non lazy" ways? ;-) (nudge)
I will choose a path that's clear. I will choose freewill.
New Depends
If I needed to update 50MM records in oracle, and I was worried about rollback / undo segments, and I was worried about speed, I'd do an PL/SQL bulk update in batches of 50,000 records.

Of course, it took me about 3 days to figure out an acceptable method of easyness and speed. I'd then write a Perl scripts to generate the PL/SQL and run it, wrapped in some decent reporting. Which then turned it into a simple perl script that said:

ora_update.pl --target_table=emp --source_table=emp --tmp_table=tmp_data --from_field=source_data --to_field=dest_data --join_key=emp_idx

Then I'd never need to think about it again, at least until someone asks how I'd do it.

You get the idea.
New Maybe not so simple then
I assumed this was an easy thing to do. Guess I'll do the temp table. This is a one-time maintenance job (yes, really) so I won't need something fast or repeatable.
--

Drew
     Dumb SQL question - (drook) - (12)
         My lazy way - (crazy) - (3)
             You have ... - (beepster) - (2)
                 Depends - (crazy) - (1)
                     Maybe not so simple then - (drook)
         Did you try a self-join? - (static) - (1)
             Not yet, but about to - (drook)
         And then there is the (ugly) semi-manual way - (CRConrad) - (5)
             This is also good for invasive updates. - (static)
             That's my kind of ugly - (drook) - (2)
                 It's also an interesting lesson in pragmatism. - (static) - (1)
                     I've done round trips mySQL -> vim -> PHP -> mySQL - (drook)
             Another batching method - (jay)

IANK.
73 ms