Re: Fast insertion indexes: why no developments

<div dir="ltr"><div class="gmail_extra"><br /><br /><div class="gmail_quote"><blockquote class="gmail_quote"
style="margin:00 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 30 October 2013 11:23, Leonardo Francalanci
<<ahref="mailto:m_lists@yahoo.it" target="_blank">m_lists@yahoo.it</a>> wrote:<br /><br /> >> In terms of
generality,do you think its worth a man year of developer<br /> >> effort to replicate what you have already
achieved?Who would pay?<br /></blockquote></div><br /></div><div class="gmail_extra">I work on an application that does
exactlywhat Leonardo described. We hit the exact same problem, and came up with the same exact same solution (down to
the15 minutes interval). But I have also worked on other various datamarts (all using Oracle), and they are all subject
tothis problem in some form: B-tree indexes slow down bulk data inserts too much and need to be disabled or dropped and
thenrecreated after the load. In some cases this is done easily enough, in others it's more complicated (example: every
day,a process imports from 1 million to 1 billion records into a table partition that may contain from 0 to 1 billion
records.To be as efficient as possible, you need some logic to compare the number of rows to insert to the number of
rowsalready present, in order to decide whether to drop the indexes or not).<br /><br /></div><div
class="gmail_extra">Basically,my point is that this is a common problem for datawarehouses and datamarts. In my view,
indexesthat don't require developers to work around poor insert performance would be a significant feature in a
"datawarehouse-ready"DBMS.<br /><br /></div><div class="gmail_extra">Yann<br /></div></div>