"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > Tom Lane <t...@sss.pgh.pa.us> wrote: >> I had wondered whether it'd be worth optimizing that along the >> lines of slot_getallattrs(). But most indexes probably have only >> one column, or anyway not enough to make for a useful savings. >> From a heavily-used production database: > cir=> select indnatts, count(*) from pg_index group by indnatts > order by indnatts; > indnatts | count > ----------+------- > 1 | 200 > 2 | 684 > 3 | 155 > 4 | 76 > 5 | 43 > 6 | 13 > 7 | 2 > 9 | 1 > (8 rows) > This includes system table and TOAST table indexes (which seem to > have two columns).
Yeah, TOAST indexes are 2-column. It would be best to exclude those from your counts, since it seems pretty unlikely that anyone will care how fast nodeIndexonlyscan.c is for scans on toast tables. > There are over 400 user tables, each of which > has a primary key, so most primary keys in our database are more > than one column. It doesn't look to me like the mean is above 2 (unless you have many fewer toast tables than I suspect), so trying to optimize many-column cases isn't going to help. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers