GiST nitpicks I want to discuss (and maybe eventually fix)

Hi hackers!

There are several things in GiST that trigger me when I think about
them. They are minor by themselves and maybe are not worth the trouble
fixing alone... But I decided to create a thread to discuss if we
should do anything about them.

0001:
Remove GistTuplesDeleted support from GiST

This bit flag value is unused since
68446b2c87a2aee5d8c2eb2aade7bb6d4195b7e1.
F_TUPLES_DELETED flag is not removed, since it is still used for
pageinspect. This is because we will still have this flag in mask
after a major upgrade, so we should keep page inspect code that
displays it. Patch merely suggests not to set it anymore.

(there was 0002, but I self-rejected it, because it is too picky)

0003:

Remove block field from gistxlogPageReuse walrecord.
GIST_REUSE_PAGE is spectail WAL record. It does not reference any
page, does not change any page in redo, its sole purpose is to kill
standby-queries which might still observe GiST index page we want to
reuse. It has `block` field which is simply not used for any purpose.
I propose to remove this field, reducing WAL footprint by an enormous
4 byte-per-record.

0004:
Reduce GIST_MAX_SPLIT_PAGES to some sane limit.

Value of GIST_MAX_SPLIT_PAGES is too big. There is no chance that GiST
page split will successfully produce 75 new pages, because there is an
upper limit of how many backup blocks a single WAL record can
reference (XLR_MAX_BLOCK_ID = 32). Patch reduces to
GIST_MAX_SPLIT_PAGES and adds static assertion for value.

Some history:
commit introducing GIST_MAX_SPLIT_PAGES [0]
commit introducing XLR_MAX_BLOCK_ID [1]

[0] was committed before [1]

I was able to create a case where split produces 6 pages. I was not
able to do more. So, I dont know if there is any real-life case where
this problem reproduces.

[0] https://github.com/postgres/postgres/commit/04e298b826d4
[0] https://github.com/postgres/postgres/commit/2c03216d8311

--
Best regards,
Kirill Reshke