Re: 1- and 2-dimensional indexes on same column: why is the 2d one preferred?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marinos Yannikos <mjy(at)geizhals(dot)at>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: 1- and 2-dimensional indexes on same column: why is the 2d one preferred?
Date: 2009-03-23 23:26:59
Message-ID: 4846.1237850819@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Marinos Yannikos <mjy(at)geizhals(dot)at> writes:
> Recent versions of PostgreSQL seem to prefer 2d indexes somehow:
> for a table "foo" with
> "i_a" btree (a)
> "i_ab" btree (a, b)

> SELECT * FROM foo WHERE a=123
> will often use "i_ab" and not "i_a" (even right after ANALYZE).

I suspect that these indexes are exactly the same size --- look at
pg_class.relpages or use the pg_relation_size() function to verify.
If they are, the computed access cost will be exactly the same and
which one gets picked is an implementation artifact. (I think that
in the current code the one that has the larger OID gets picked,
but that's not something I'd suggest you rely on.) It wouldn't
really matter anyway because the actual runtime should be pretty
much the same too.

The most likely reason for this to happen is that you're talking
about two int4 columns and you're on a 64-bit machine that is
going to align index entries to 8-byte boundaries. The one-column
index isn't actually any smaller because of alignment padding :-(

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2009-03-23 23:33:18 Re: Determining/Setting a server's time zone
Previous Message Whit Armstrong 2009-03-23 23:25:30 Re: libpq -- reading a timestamp with time zone using binary format