What's the cost of CHECK constraints in Postgres 9.x?

Question

I have a table with 60 columns. 20 of those are "NotEmpty" and 6 "NotNull".

I have empty values and Null values (which always mean "no data" in my case). I'd like to unify columns with just one type of constraint.

I have read null values are cheap (in byte size). So maybe use NotEmpty constraints? But maybe NotNull constraints perform better? Or maybe it's better to have both values and use coalesce() when retrieving data?

What's the cost of CHECK constraints for INSERT and UPDATE in Postgres 9.x? What's about your experience? Any benchmarks?

Gentle

Null checks are a bit faster (there's a flag in the catalog) but you almost certainly have more important things to be worrying about. – Snowcap

Answer 1

Some people try to avoid NULL values, claiming the logic would be confusing.

I am not one of them. NULL values are just fine for columns with no data. They are certainly the cheapest way to store "empty" columns - for disk space as well as performance (the main effect being smaller tables and indices):

• Does not using NULL in PostgreSQL still use a NULL bitmap in the header?
• Does setting "NOT NULL" on a column in postgresql increase performance?
• Do nullable columns occupy additional space in PostgreSQL?

Once you understand the nature of NULL values, there is no reason to avoid them. Postgres offers a variety of functions to deal with NULLs. colaesce(), nullif(), concat(), concat_ws(), ...

Generally, as far as performance is concerned, a NOT NULL constraint beats a CHECK constraint and both beat triggers by a log shot. But even simple triggers are cheap. The cost of a NOT NULL constraint is next to nothing. Also, all of these only affect write operations, but in most applications read operations dominate.

The most relevant impact on performance (sub-optimal indices and queries aside) therefore is the size of tables and indices or, more importantly, the number of tuples per data page. Bigger tuples lead to slower performance for most use cases. The number of data pages that have to be read to satisfy a query increases accordingly. Available cache memory is saturated earlier.

I don't have a benchmark ready, but it's best to test for your particular environment anyway. These are just simple rules of thumb. Reality is a lot more complex.

Lebkuchen

I do not want to run away from the NULLability but i'd like to unify absence of data between NULL and EMPTY. My question is, in terms of performance, it is best to use NULL and have a CHECK CONSTRAINT on EMPTY or store EMPTY and have a NOT NULL CHECK CONSTRAINT? From your link, all interesting, stands out storing lightness of NULL compared to any other. How that "NULL lightness" improve performance compared with CHECK constraint EMPTY values? That's my explained question. – Gentle