From: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Some refactoring of index structures . |
Date: | 2016-02-10 17:46:48 |
Message-ID: | 56BB7788.30808@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, hackers.
Long story short, I'd like to do some refactoring of the code related to
indexes.
I work on patch which provides INCLUDING columns functional [1]. The
patch was reviewed again and again, I fixed many issues, but we still
don't sure enough that all occurrences of /rd_index->indnatts/ are
replaced with /rd_index->indnkeyatts /accurately. I have no idea how to
do it without thorough reading of code, so I am doing it now.
I already replaced all these /rd_index->indnatts ///with macro
/IndexRelationGetNumberOfAttributes/ and /rd_index->indnkeyatts /with
macro /IndexRelationGetNumberOfKeyAttributes/. But still there are a lot
of places with vague naming.
For example, /indnatts/, /natts/, /ncolumns/ and so on for the very same
/rd_index->indnatts. /I changed them with /indnatts./
Or /indexStruct, index, idxForm, index_form/ for /index->rd_index./ They
are definitely should be unified. I'd prefer indexForm. Any objections?
One more point is indkey in FormData_pg_index
<http://doxygen.postgresql.org/pg__index_8h.html#a5065be0408f03576083a30c97b43a09a>.
The same for indkeys
<http://doxygen.postgresql.org/struct__indxInfo.html#a66d6eab0efe4bcb9fcbb472d403fa981>,
ii_KeyAttrNumbers
<http://doxygen.postgresql.org/structIndexInfo.html#a7723798af613a780d505231bad72c0a3>
, indexkeys
<http://doxygen.postgresql.org/structIndexOptInfo.html#ab95b0da6ff1e527506239dab1a480b82>.
With my patch index can have key and non-key (included) columns.
Therefore indkey is not just the key now. It contains both key and
included columns. And its length is not indnkeyatts as one might think,
but indnatts. I suppose it's worth to rename it somehow. But I can't
find the proper name. Do you have any ideas?
If you see any related changes, please, let me know.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2016-02-10 17:50:56 | eXtensible Transaction Manager API (v2) |
Previous Message | Craig Ringer | 2016-02-10 17:45:24 | Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. |