From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | alvherre(at)2ndquadrant(dot)com |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: BRIN index and aborted transaction |
Date: | 2015-07-18 14:38:53 |
Message-ID: | 20150718.233853.504312811018491111.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro,
Thank you for the explanation. It's really helpfull.
>> Second question is when the wrong summary data is gone? It seems
>> vacuum does not help. Do I have to recreate the index (or reindex)?
>
> Yeah, that's a bit of an open problem: we don't have any mechanism to
> mark a block range as needing resummarization, yet. I don't have any
> great ideas there, TBH. Some options that were discussed but never led
> anywhere:
>
> 1. whenever a heap tuple is deleted that's minimum or maximum for a
> column, mark the index tuple as needing resummarization. One a future
> vacuuming pass the index would be updated. (I think this works for
> minmax, but I don't see how to apply it to inclusion).
>
> 2. have block ranges be resummarized randomly during vacuum.
>
> 3. Have index tuples last for only X number of transactions, marking the
> as needing summarization when that expires.
>
> 4. Have a user-invoked function that re-runs summarization. That way
> the user can implement any of the above policies, or others.
What about doing resummarization while rechecking the heap data?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-07-18 15:14:34 | Re: [Postgresql Master Branch Patch] object class patch |
Previous Message | Petr Jelinek | 2015-07-18 13:42:38 | Re: pg_resetsysid |