Change in anonymization of plans on explain.depesz.com

As you perhaps know, explain.depesz.com has anonymization feature.

Couple of days ago Filip contacted me and sent a patch that stopped anonymization of typecasts.

I thought about the patch, and what it achieves, changed it's internals, but kept the effect. And today, it got released.

Normal plan looks like this.

But you might want to hide names of columns, tables, or even string values used.

So, anonymization, up to version 0.61 of Pg::Explain class, changed the explain to this.

Which works – we no longer know what was the table name, nor the string searched or the column name.

But – the ::golf and ::charlie typecasts are not really necessary – the fact that you're using standard datatypes of PostgreSQL cannot be of any harm. And hiding it can lead to problems with debugging queries.

Thanks to Filip idea and (at least partially) his code, anonymization now produces this output.

As you can see column name, table name and the literal text are still anonymized, but typecasts (to standard pg types) are left intact.

To elaborate on “standard pg types" part. I took list of all types in vanilla PostgreSQL 9.2 (using query that can be seen in source, and made regexp that matches only those types. So that when you'll have your own special, proprietary datatype – its name will be anonymized out of explains.

Usually, when writing about explain.depesz.com, I brag about numbers. This time will not be different. Here comes stats (as of now: Tue, 31 Jan 2012 12:55:25 +0100):

      Total count of plans: 29861
      Count of private plans: 13317 (46.4% since the feature was introduced)
      Count of anonymized plans: 1519 (11.7% since the feature was introduced)
      Count of plans with titles provided: 1046 (8.5%)
      Daily added plans (average of last 60 days): 60.7
      Last day without any new plans: 2011-05-15

3 thoughts on “Change in anonymization of plans on explain.depesz.com”

  1. In your exmple, replacing the column name oid wouldn’t be necessary either, right? As oid is standard column name (much like standard data types) it would not reveal anything about the underlying table (unless I’m missing something?)

  2. @Thomas:
    well, technically – yes. But. use of standard columns (like system columns) is much less common, so I’m not inclined to add special cases for them. casts to standard types happen in most of the cases, so adding specific “whitelisting” to them makes more sense.
    On the other hand – if you’d provide a patch that would do it – I most likely wouldn’t object applying it 🙂

Comments are closed.