Re: BRIN indexes (was Re: Minmax indexes)

Поиск
Список
Период
Сортировка
От Emanuel Calvo
Тема Re: BRIN indexes (was Re: Minmax indexes)
Дата
Msg-id 54163C0F.7060907@esdebian.org
обсуждение исходный текст
Ответ на BRIN indexes (was Re: Minmax indexes)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
<br /><div class="moz-cite-prefix">El 08/09/14 13:02, Alvaro Herrera escribió:<br /></div><blockquote
cite="mid:20140908160219.GN14037@eldon.alvh.no-ip.org"type="cite"><pre wrap="">Here's version 18.  I have renamed it:
Theseare now BRIN indexes.
 

I have fixed numerous race conditions and deadlocks.  In particular I
fixed this problem you noted:

Heikki Linnakangas wrote:
</pre><blockquote type="cite"><pre wrap="">Another race condition:

If a new tuple is inserted to the range while summarization runs,
it's possible that the new tuple isn't included in the tuple that
the summarization calculated, nor does the insertion itself udpate
it.
</pre></blockquote><pre wrap="">
I did it mostly in the way you outlined, i.e. by way of a placeholder
tuple that gets updated by concurrent inserters and then the tuple
resulting from the scan is unioned with the values in the updated
placeholder tuple.  This required the introduction of one extra support
proc for opclasses (pretty simple stuff anyhow).

There should be only minor items left now, such as silencing the 

WARNING:  concurrent insert in progress within table "sales"

which is emitted by IndexBuildHeapScan (possibly thousands of times)
when doing a summarization of a range being inserted into or otherwise
modified.  Basically the issue here is that IBHS assumes it's being run
with ShareLock in the heap (which blocks inserts), but here we're using
it with ShareUpdateExclusive only, which lets inserts in.  There is no
harm AFAICS because of the placeholder tuple stuff I describe above.
</pre></blockquote><br /> Debuging VACUUM VERBOSE ANALYZE over a concurrent table being updated/insert.<br /><br />
(gbd)<br/> Breakpoint 1, errfinish (dummy=0) at elog.c:411<br /> 411        ErrorData  *edata =
&errordata[errordata_stack_depth];<br/><br /> The complete backtrace is at <a class="moz-txt-link-freetext"
href="http://pastebin.com/gkigSNm7">http://pastebin.com/gkigSNm7</a><br/><br /><br /> Also, I found pages with an
unkowntype (using deafult parameters for the index<br /> creation):<br /><br />  brin_page_type | array_agg<br />
----------------+-----------<br/>  unknown (00)   | {3,4}<br />  revmap         | {1}<br />  regular        | {2}<br />
 meta          | {0}<br /> (4 rows)<br /><br /><br /><br /><br /><blockquote
cite="mid:20140908160219.GN14037@eldon.alvh.no-ip.org"type="cite"><pre wrap="">
 
</pre><br /><fieldset class="mimeAttachmentHeader"></fieldset><br /><pre wrap="">
</pre></blockquote><br /><pre class="moz-signature" cols="72">-- 
--
Emanuel Calvo
@3manuek</pre>

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

Предыдущее
От: Arthur Silva
Дата:
Сообщение: Re: [REVIEW] Re: Compression of full-page-writes
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgbench throttling latency limit