[and here i had my description of the problem typed up somewhere else and lost it so I'll have to start anew] well, that's procrastination for you. ;)
teachers create student accounts for their classes -- they do this just by writing in a list of students' names (first, last, middle). the system needs to autogenerate usernames and password for these students. passwords are easy -- they can be funky and don't need to be unique. usernames are, to follow convention, some part of the first and last names glommed together, truncated. I don't want to waste a select on every student creation. (maybe I should??) If I don't, then I simply attempt an insert -- if it works, good, if it bails on non-uniqueness... THEN I do a select? (to find the smallest positive integer I can append to the username that would make it unique). I suppose that's a balanced way to do it. not too much of a performance hit when necessary. But an INSERT, even with constraint checking, is (I think) more expensive than a SELECT. so where's the middle ground -- how big would the system have to be for this to be more expensive overall than doing a select before every insert?
and how slow is any of this ANYWAY?
Just found out how to turn on statistics logging for postgresql. I think. I've had it running for a few hours now. (I hope). Maybe I'll learn something with that (for my other sites)
and hibernate is being weird. It seems to keep around three "idle in transaction" postgresql threads. and when I restart the webapp/container, it doesn't lose them. I think it does lose them if I actually shut down resin itself. meh. at least I know they're there and can kill them manually. I suppose since I can kill them manually I *could* write something to kill them automagically. but. eh. that would mean system calls. that's not healthy.
[this is NOT the post I meant to post.]
I need to writeup the shenanigans at the sf peace march thinger yesterday.
That will happen. Some photos posted. Nothing spectacular.