wulczer

But that's because IBM has a strong presence in the SQL standard committee and can nudge it to standarise (post-factum) things they already implemented in DB2.

Since all of the previous states are there in the repo history, you can make that gif yourself at any moment!

Postgres at least will store rows roughly in insert order. So whether you're using integers or UUIDs for primary keys won't affect on-disk layout.

When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.

Sorry, ticked off my OCD :)

It's better to say "key text" instead of "key varchar(1024)" and primary key already implies not null.

Thanks!

We're staying in Spain and there are plans to further grow the Barcelona office.

What is the epiphany here? What is the insight or enlightenment to be gained from this story?

I have my own, but I'm curious about what people believe is the moral of the story.

That's also why, when you go to the movies and it turns out tickets cost the same regardless of the film, you should go for the one with the longest running time.

One of the important reasons Postgres connections are serviced by a separate process is that if that process segfaults, you only disconnect other connections (because if might have tainted shared memory when it died), but the main database process keeps running and you can reconnect immediately.

Logs subpoenaed from your ISP show that you were using Tor between 3:10 and 5:23 PM on 02/05/2012.

Logs from forensic analysis of a breakin to EvilCorp show that the attacker came in from Tor and was downloading secret data from 3:10 to 5:23 PM on the same day.

Not enough to prove anything, but there's definitely some circumstantial evidence there.

Why can't you use a connection that has issued LISTEN for anything else? In fact, I'm fairly sure you can use it normally.

We're using NOTIFY to broadcast database changes to services that should react to them and it's quite a nice way to separate concerns: process A just writes to the database, a trigger issues a NOTIFY, process B checks and notices there's been a change.

Edit: I see, the code in the post suggests that the connection needs to be stuck in a select() (I should know, I contributed a largre chunk of psycopg2's async code handling). You just need to use an asynchronous driver and you can happily LISTEN and do queries at the same time (of course you won't get notifies while a query is processing - the Postgres protocol has no concept of multiplexing).

We're using Twisted and happily mixing queries and NOTIFY.