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,
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
Hope you find useful these numbers.
El sáb., 13 jun. 2015 a las 11:41, deavid (deavidsed...@gmail.com)
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.
El sáb., 13 jun. 2015
El vie., 19 jun. 2015 a las 15:06, Simon Riggs (si...@2ndquadrant.com)
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
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 (deavidsed...@gmail.com)
escribió:
So I just ran a test case for hash, btree, gin_btree and brin
