In my mind, the code is a lot more malleable than the database is. There's nothing inherently wrong with the database. In fact, none of our SQL queries will need to change, just how they're executed in the code.

There's nothing inherently wrong with the database

Well, except it's not as full featured as I'd prefer, and there's that bug Rob found.

I've wanted to change to Postgres since shortly after we went live. It's completely unrelated to the connections issue.

What I'm wondering -- if the back end change is a given, how does that affect your urgency on the page model change?

if the back end change is a given, how does that affect your urgency on the page model change?

The new-connection-for-each-transaction thing needs to be fixed, no matter what database we're using. There should be one sql connection per page view (and if those connections can be cached across page views, even better).

If the loading-the-entire-query-into-memory thing could be fixed for just threadsuck, that would probably be good enough.

The new-connection-for-each-transaction thing needs to be fixed

That can be done really quickly -- because if the connection isn't closed at the end of the transaction (as it originally wasn't -- the change was made as a response to the errors), it's one connection per page. But we're still fucked that way. MySQL doesn't like counting.

And to cache across views, isn't that where pconnect comes in? With suitable server tuning? Very little code changes there.

The loading the whole page thing is a larger change, though.

The counting part of MySQL that was broken had to do with the per-user connection limit. We don't have that turned on here, so there shouldn't be an issue. Taking out the explicit closes would be a good thing to do now.

Explicit closes are now gone.

So Tom, are you a choc chip, oatmeal, or sugar cookie kind of guy? Step up, claim your baked goods. Otherwise you'll get some low-fat no sugar spelt bread, and really, we all know you don't want that.

Maybe it's just how threads show up in a Linix ps listing.

Nitpick - it's spelt Linux. Also, yes, each (heavyweight) thread shows up in the ps listing, unlike BSD and some Unices.

Tom, I would seriously recommend writing a test case and comparing the performance of a 'threadsuck' type exercise with the connectAndQuery route versus the row-by-row-fetch route. MySQL was originally designed as a database with -very- (compared to something like PostgreSQL or Oracle) lightweight connections. Let's try hard to quantify the difference here before we talk about re-writing whole sections of code.

ita, Tom, I know this may be the worst possible time to bring any side things up, but I've been very concerned lately with our lack of a filter, especially given the number of resignations we've had.

I know Paul was working on one for us, and then got hella busy with work -- did you ever get anything from him, be it design notes or partial code or anything in between?

Now that you're talking about fundamental code changes, I don't want to just seem to be agitating for what may only be my pet issue. But if there's anything to work with that won't be totally Jossed next week and won't get in your way, I'm willing to do whatever it takes to get a filter going.

I won't even whine any more about how I hate stupid acronymic names like MARCIE. I promise.

It had never occurred to me that filters and resignations might be related.

However, if we agree that changing the underlying mechanism of how the pages are presented is important, I'd like us to scope it before writing new changes. Just so we don't make more work for ourselves.

Filtering is good, and demanded by many people, but I think board health is more important.