| > Storing "foreign keys" in an array column, instead of using a join table Very bad idea for a base table, sure. OTOH, potentially great idea for a (possibly materialized) view (as might eagerly storing an array of row values instead of keys.) > Storing binary files as base64 encoded strings in text columns That might not be a bad idea depending on size, and depending on how often you needed the binary vs. a base64 encoded string: if most of the use of the binary is in a context where it will be sent as base64 encoded, storing it that way might be a great idea. > Using a table with `key` and `value` string columns instead of using redis If you need an in-memory cache, sure. Otherwise...you could use redis, but I’m not sure why it would always be preferred. > Pub/sub using NOTIFY/LISTEN - Message queueing NOTIFY/LISTEN are a pub/sub mechanism. You shouldn’t use them alone as an application level message queueing system, but you definitely can build such a system on PG and might well use NOTIFY/LISTEN in the implementation. > - Storing executable code There are probably problems that involve specific instances of doing this, but this is at best to general to describe a thing yoi shouldn’t do. |
We did switch to using binary queries though (by passing result_format as 1), and at that point we did see a speedup from using bytea columns - but it’s quite a bit of work to get the type mapping correct then so probably not worth it in most cases