From: | Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Microvacuum for gist. Question about GISTPageOpaqueData flag |
Date: | 2015-07-27 15:10:55 |
Message-ID: | CAP4vRV7LeB4fQQAjxvdygSdR+SbUJMy-XN=T=vg+047zaCXNAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I'm working on microvacuum for gist access method.
Briefly microvacuum includes two steps:
1. When search tells us that the tuple is invisible to all transactions it
is marked LP_DEAD and page is marked as "has dead tuples",
2. Then, when insert touches full page which has dead tuples it calls
microvacuum instead of splitting page.
You can find a kind of review here [1].
While writing patch, I found strange GISTPageOpaqueData flag -
F_TUPLES_DELETED
<http://doxygen.postgresql.org/gist_8h.html#a23812efd70313b9b10ae61376e2594f6>
.
Its description looks like it is the same for BTP_HAS_GARBAGE
<http://doxygen.postgresql.org/nbtree_8h.html#a3b7c77849276ff8617edc1f84441c230>
#define F_TUPLES_DELETED (1 << 2) /* some tuples on the page are dead */
#define BTP_HAS_GARBAGE (1 << 6) /* page has LP_DEAD tuples */
But it's definitely not the same things. I found only two mentions of this
flag.
Function GistMarkTuplesDeleted
<http://doxygen.postgresql.org/gist_8h.html#a96fc3c6bb5aecfc8d2818b7010d68aac>
sets
the flag after dead tuples deletion.
Do anyone need it at all? I found no place where this flag is checked.
Is it correct using of the flag?
I need an advice, what would be better:
- to add new flag like F_HAS_GARBAGE,
- or to delete all mentions of F_TUPLES_DELETED and use it in gist
microvacuum.
[1]
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/ivanitskiy_ilya/5629499534213120
--
Best regards,
Lubennikova Anastasia
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-07-27 15:17:31 | Re: Reduce ProcArrayLock contention |
Previous Message | Tom Lane | 2015-07-27 14:28:47 | Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c |