Postgres 12: Are there performance differences between PRIMARY KEY(A, B) and PRIMARY KEY (B, A) on a table PARTITION BY (A)?

Question

Given a table this table:

CREATE TABLE tbl (
  a int not null,
  b int not null,
  created timestamp not null default now(),
  primary key(a, b)
) PARTITION BY LIST(a)

The query plan for a lookup on columns a and b looks like this:

EXPLAIN ANALYZE SELECT EXISTS(SELECT * FROM tbl WHERE a = 1 AND b = 1)

Result  (cost=2.37..2.38 rows=1 width=1) (actual time=0.013..0.013 rows=1 loops=1)
  InitPlan 1 (returns $0)
    ->  Index Only Scan using pkey on partition  (cost=0.15..2.37 rows=1 width=0) (actual time=0.012..0.012 rows=0 loops=1)
          Index Cond: ((a = 1) AND (b = 1))
          Heap Fetches: 0
Planning Time: 0.860 ms
Execution Time: 0.033 ms

I'm wondering if defining the primary key in reverse column order (PRIMARY KEY (b, a) ) PARTITION BY LIST (a)) results in better performance as the index used in the lookup contains the interesting column first, as filtering by a is already achieved by the query planner picking a single partition to run the query on.

Answer 1

No, that will make no difference; the order of the columns in the index doesn't matter if both columns are compared with = in the WHERE condition (of course only if there is AND between the conditions).

The index will be scanned using both columns at the same time, and all that matters is the number of index entries that match the condition, which will be the same in both cases:

  a  |  b           b  |  a
-----+-----       -----+-----
   1 |  -1          -1 |   1
   1 |   1  <---    -1 |   2
   1 |   1  <---     1 |   1
   1 |   2           1 |   1  <---
   2 |  -1           1 |   2  <---
   2 |   1           2 |   1
   2 |   3           2 |   3

index on (a,b)   index on (b,a)