Thread: Confusing messages about index row size

Confusing messages about index row size

From
Jaime Casanova
Date:
Hi everyone,

I tried an old test that at some point crashed the database... that is
already fixed.

So now it gives a good ERROR message:

"""
postgres=# create table t1 (col1 text, col2 text);
CREATE TABLE
postgres=# create unique index on t1 ((col1 || col2));
CREATE INDEX
postgres=# insert into t1 values((select array_agg(md5(g::text))::text from
postgres(# generate_series(1, 256) g), version());
ERROR:  index row requires 8552 bytes, maximum size is 8191
"""

great, so I reduced the length of the index row size:

"""
postgres=# insert into t1 values((select array_agg(md5(g::text))::text from generate_series(1, 200) g), version());
ERROR:  index row size 6704 exceeds btree version 4 maximum 2704 for index "t1_expr_idx"
DETAIL:  Index row references tuple (0,1) in relation "t1".
HINT:  Values larger than 1/3 of a buffer page cannot be indexed.
Consider a function index of an MD5 hash of the value, or use full text indexing.
"""

So, what is it? the index row size could be upto 8191 or cannot be
greater than 2704?

regards,

-- 
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL



Re: Confusing messages about index row size

From
"David G. Johnston"
Date:
On Sunday, September 12, 2021, Jaime Casanova <jcasanov@systemguards.com.ec> wrote:

So, what is it? the index row size could be upto 8191 or cannot be
greater than 2704?

The wording doesn’t change between the two: The size cannot be greater the 8191 regardless of the index type being used.  This check is first, probably because it is cheaper, and just normal abstraction layering, but it doesn’t preclude individual indexes imposing their own constraint, as evidenced by the lower maximum of 2704 in this specific setup.

It may be non-ideal from a UX perspective to have a moving target in the error messages, but they are consistent and accurate, and doesn’t seem worthwhile to expend much effort on usability since the errors should themselves be rare.

David J.