November 12th, 2007


Queue Engine, A little more effort...

This is not one of my big focuses, but I did put together a queue engine many months ago (

The semantic idea was that when you SELECT data the person who selects data gets a limited period of time to see the data.

An example is if I inserted 5 records, and then did a "SELECT ... LIMIT 3" I would get three rows. If another user selected data after my data and did a "SELECT ... LIMIT 3" they would only get two records (and this would be the 4th and 5th record).

Right now the period of "exclusion" for reading a record is 60 seconds. Anyone can always fetch and delete a record based on primary key (and you would want to delete records before the 60 seconds are up if you want them removed from the queue). Using triggers you can use a queue table to control for instance the data in an Innodb table.

For those who need a queue service this should hopefully make a lot of sense, for anyone else it probably sounds pretty confusing :)

Here is the tarball I put together:

From revision control:

This is not a project I am planning on putting a lot of energy in. It is highly useful though, so I will happily except patches (at the moment the code is only safe on a single CPU system BTW). I've had a number of people comment on it/play with it, so I thought it would be good to clean up the code a little for others.

While I have a need for this, it is not a pressing need.

One final thought, think of this as a service for other engines. I do not see a reason at the moment to make the engine durable, with triggers you really can use any engine as the durable store. The original plan for "partitioning" was to make it a similar service. Not all new storage engines need to be stand alone "engines", I believe there is market place for extensions to current engines.

Oil, $100 a barrel

Looking at the market reaction to the stock plunge made me wonder when oil would hit $100 a barrel.

The difference in cost? Well at around $94 a barrel right now the percentage of difference in price is slight... but...

Psychologically what does this do? People are still driving to work, and I bet that few have given up cars based on the price of gas (for daily commutes, vacations are another thing), but at what price do people question their own consumption?

Last week in Washington we had a vote for a new road bill. The bill had a lot of mass transit tossed in to counter the impression that it was only a road bill, but in the end it was a road bill.

It was also a bill to extend 520, and as far as I am concerned I am not voting for anything which widens the road going through the arboretum or damages the arboretum in any other way.

I would rather vote separately on mass transit and roads. Sure, they work hand in hand, but I am willing to shell out more for rail then what I am for roads.

If oil hits a certain price then mass transit has to pick up, which in theory could lower road usage (though this is a naive view of what the outcome is... where there is capacity someone will use it). If I figure in total cost though... I help pay for the roads and then I pay for the gas, how does this compare to me paying for a share mass transit plus a ticket?

There is a shared cost in either case, roads or mass transit. For those who just drive, mass transit is mitigation costs. Mitigate the need for more roads (or hell... more open space for driving faster).

How this will work out in my lifetime?

Two more years before I can take light rail to SeaTac.

And if I were to dream a bit?

Within 15 years Seattle, Portland, and Vancouver are tied together with a European style bullet train. The cities would be linked together.

30 years out? San Francisco to Seattle via a bullet train. Have it run around 300 miles per hour. Link the economies of the west coast together.