El vie., 19 jun. 2015 a las 15:06, Simon Riggs ()
escribió:
> It doesn't say anything about their being only one index buffer per table,
> nor do I think it would make sense to do it that way. So ISTM that the
> foreground process still has to insert serially into N index buffers, with
> each inse
very very
small
Hope you find useful these numbers.
El sáb., 13 jun. 2015 a las 11:41, deavid ()
escribió:
> Sorry; Because some misconfiugration vacuum and analyze were'nt working.
> Now I'm getting better numbers for BRIN indexes where there are zero rows
> to match.
>
>
Sorry; Because some misconfiugration vacuum and analyze were'nt working.
Now I'm getting better numbers for BRIN indexes where there are zero rows
to match.
El sáb., 13 jun. 2015 a las 3:17, deavid ()
escribió:
> So I just ran a test case for hash, btree, gin_btree and brin in
x27;m not going to test them again.
And finally, don't know why but i couldn't vacuum or analyze tables. It
always get stalled without doing anything; so i had to comment every
vacuum. Maybe there is a bug in this dev version or i misconfigured
something.
El vie., 12 jun. 2015 a las 7:
b., 6 jun. 2015 a las 13:07, k...@rice.edu () escribió:
> On Fri, Jun 05, 2015 at 11:54:01PM +, deavid wrote:
> > Thanks to everybody for answering. I wasn't expecting this attention;
> this
> > is a great community :-)
> >
> > Jim asked me about something rea
Thanks to everybody for answering. I wasn't expecting this attention; this
is a great community :-)
Jim asked me about something real. Well, the problem is this showed up more
than five years ago, and keeps popping from time to time since in different
circumstances. I solved them in different ways
There are several use cases where I see useful an index, but adding it will
slow too much inserts and updates.
For example, when we have 10 million rows on a table, and it's a table
which has frequent updates, we need several index to speed up selects, but
then we'll slow down updates a lot, specia
