yangyang

Er, I'd have to say that at the moment it's almost certainly just me :-). I have two of these clocks, and I'm planning to put one in an enclosure and give it to my niece, so I suppose then there will be two.

I don't think there are that many people who own these things, and of those that do, the ones willing to buy an ISP programmer, compile this and program it are probably a fairly small percentage.

On a related note, I wrote a Tetris clone [1] for the JY-MCU-3208 "dot matrix clock" [2] available from DX.com, Banggood etc., recently. It's in C, runs on the ATmega8L on this clock.

[1] https://github.com/hollobon/jy-mcu-3208-tetris

[2] http://www.dx.com/p/jy-mcu-3208-lattice-clock-ht1632c-driver...

Well that's pretty much what a hash join is doing - scan a table creating a hash table (effectively an in-memory index), then scan the inner table looking up values in the hash table.

A hash table is a more effective data structure than a btree for in-memory search.

Some interesting ideas here.

One thing I noted in a quick play with it on Windows: if you right-drag outside the window, it doesn't get the mouse-up event and you have to right click in the window again to stop it panning.

I'd be very interested to know more about this too. There is considerable overhead for each row in PostgreSQL (24 byte header, which must be aligned). Obviously you'll save a bit if there are repeated keys higher up, but you'll pay for the foreign key references to those rows in the children.

Amazon RDS for PostgreSQL also supports SSDs [1]:

"Amazon RDS now supports General Purpose (SSD) Storage You can now launch DB Instances that use General Purpose (SSD) storage, a new SSD-backed storage option for Amazon RDS"

[1] http://aws.amazon.com/rds/postgresql/

Also, if you have any untrusted PLs available, a superuser can create one of those and do what they like.

Apologies - I was thinking of ALTER SYSTEM [1]. That writes to postgresql.auto.conf. It sounds like that file has priority over postgresql.conf [2]. You might well be able to just prevent writes by the postgres user (or whatever user you're running postgres as).

Regarding superusers overwriting files - COPY can write to anywhere on the filesystem. From the docs "COPY naming a file is only allowed to database superusers, since it allows reading or writing any file that the server has privileges to access." [3].

[1] http://www.postgresql.org/docs/9.4/static/sql-altersystem.ht...

[2] http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-...

[3] http://www.postgresql.org/docs/current/static/sql-copy.html

That sounds sensible, thanks; I'd misunderstood and thought you were doing continuous replication to another PG server, now I realise you're archiving WAL to S3.

OK, that sounds fair enough. Just interested in whether you'll be running a patched Postgres to be honest :-).

There is of course set_config in 9.4 - superusers can then edit the config file through that (a superuser can overwrite any file the user running the server can write to anyway, but through more convoluted means).

How does that tie in with your admin of the database? What happens when a user changes wal_level or something? Just wondering where you draw the line.

Do clients get Postgres superuser access?

Replication and backup solve different problems. What if I accidentally drop a table and need last night's backup? Are they archiving the WALs too so you can do point-in-time recovery?

Are the SSDs at Digital Ocean enterprise grade and RAIDed? They won't corrupt data under power loss etc? Bearing in mind you're probably using asynchronous replication, people you can't rely on that for durability; people will expect that once it's committed, it's on on (at least 2) disks.

Thanks.

I'm not involved with it, just a Postgres user and thought it was of interest.

This is really interesting.

Did you do anything about join pushdown (which isn't supported in core PostgreSQL yet)? Apologies if this is in your talk - I looked at the slides and couldn't see anything.

Indeed: it's estimating that a single row will be returned from the seq scan. That will clearly take no time to sort!

The time taken parsing the query is insignificant compared to the time planning.

Not sure if it's exactly what you're getting at, but SQL Server has a "USE PLAN" hint that lets you set the entire query plan (using an XML string).

PostgreSQL's policy is strongly against hints, so we're unlikely to see anything like that in Postgres.

Have you seen QUEL (http://en.wikipedia.org/wiki/QUEL_query_languages)? It's the original query language used by Postgres (it gives the client library, libpq, its name).

It's not there any more - it was replaced with SQL in Postgres95, the predecessor to PostgreSQL.

It can estimate though, using per-column statistics. ANALYZE (and the autoanalyze background process) update these in PostgreSQL.

These stats are a huge part of cost-based query optimisation, which all major DBMSs do these days.

Details here: http://www.postgresql.org/docs/9.3/static/planner-stats.html

That query improvement was for a third-party extension storing data outside PostgreSQL (cstore_fdw), and has no effect on core Postgres.

There are doors but they are not for use in normal circumstances. The new Victoria Line trains were initially supposed to be "space trains", open all the way through, but didn't actually end up getting built like that.

They'd probably never close in some stations, like Victoria at rush hour :-)

Indeed - quite a lot of stations already have platform staff for checking doors and notifying the driver that it's OK to close. I suppose it would depend on the ratio of active trains to stations as it which is most efficient. I believe TfL have committed to manning all stations after the closure of ticket offices so having platform dispatch staff may be a useful use of labour.

To a point. They walk up and down the train, do the door opening / closing, check tickets here and there, and occasionally drive the train (though it always seems painfully slow when under manual control).

I don't know how they'd do it on the tube. Presumably door closing would still require manual control.

He / she edited after I replied.

They definitely had them before that incident (which was at Shadwell IIRC).

And yet the Docklands Light Railway, also in London, and also under TfL control (though operation is outsourced to Serco, soon to be Keolis/Amey) has run without drivers (but with "train captains") for its entire history, over 25 years. And it does travel underground in places.

IMCS [1] already uses SIMD vector instructions.

[1] http://www.pgcon.org/2014/schedule/attachments/322_IMCS.pdf

It sounds like it was precisely because there was more low-hanging fruit.

I think column-store databases are far more amenable to vectorised processing. I'm not aware of any row-store databases which do it, and most research into it has been on column-store (or hybrid) systems.