In the article from yesterday we talked about PostgreSQL HyperLogLog with some details. The real magic of that extension has been skimmed over though, and needs another very small article all by itself, in case you missed it.
*Which Set Operation do you want for counting unique values?* The first query here has the default level of magic in it, really. What happens is that each time we do an update of the HyperLogLog hash value, we update some data which are allowing us to compute its cardinality.
If you’ve been following along at home the newer statistics developments,
you might have heard about this new
State of The Art Cardinality Estimation Algorithm called
HyperLogLog. This
technique is now available for PostgreSQL in the extension
postgresql-hll
available at
https://github.com/aggregateknowledge/postgresql-hll and soon
to be in
debian
.
I’ve been given a nice puzzle that I think is a good blog article opportunity, as it involves some thinking and window functions.
Let’s say you need to ALTER TABLE foo ALTER COLUMN bar TYPE bigint;, and PostgreSQL is helpfully telling you that no you can’t because such and such views depend on the column. The basic way to deal with that is to copy paste from the error message the names of the views involved, then prepare a script wherein you first DROP VIEW then ALTER TABLE and finally CREATE VIEW again, all in the same transaction.
You certainly know that implementing dynamic triggers in PLpgSQL is impossible. But I had a very bad night, being up from as soon as 3:30 am today, so that when a developer asked me about reusing the same trigger function code from more than one table and for a dynamic column name, I didn’t remember about it being impossible.
Here’s what happens in such cases, after a long time on the problem (yes, overall, that’s a slow day).