Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [HACKERS] brin autosummarization -- autovacuum "work items"
Дата
Msg-id CAEepm=0FSzkxdCMMX8xR6NcAH6QZL8xkbyjTo6YAVHDPcLdHgQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] brin autosummarization -- autovacuum "work items"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [HACKERS] brin autosummarization -- autovacuum "work items"  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: [HACKERS] brin autosummarization -- autovacuum "work items"  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> I think one of the most serious issues with BRIN indexes is how they
> don't get updated automatically as the table is filled.  This patch
> attempts to improve on that.  During brininsert() time, we check whether
> we're inserting the first item on the first page in a range.  If we are,
> request autovacuum to do a summarization run on that table.  This is
> dependent on a new reloption for BRIN called "autosummarize", default
> off.

Nice.

> The way the request works is that autovacuum maintains a DSA which can
> be filled by backends with "work items".  Currently, work items can
> specify a BRIN summarization of some specific index; in the future we
> could use this framework to request other kinds of things that do not
> fit in the "dead tuples / recently inserted tuples" logic that autovac
> currently uses to decide to vacuum/analyze tables.
>
> However, it seems I have not quite gotten the hang of DSA just yet,
> because after a couple of iterations, crashes occur.  I think the reason
> has to do with either a resource owner clearing the DSA at an unwelcome
> time, or perhaps there's a mistake in my handling of DSA "relative
> pointers" stuff.

Ok, I'll take a look.  It's set up for ease of use in short lifespan
situations like parallel query, and there are a few extra hoops to
jump through for longer lived DSA areas.

-- 
Thomas Munro
http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rushabh Lathia
Дата:
Сообщение: Re: [HACKERS] [POC] hash partitioning
Следующее
От: Kuntal Ghosh
Дата:
Сообщение: Re: [HACKERS] Performance degradation in TPC-H Q18