Hi,
2011-05-12 00:28 keltezéssel, Tomas Vondra írta:
Hi,
I've studied the implementation of the btree indexes and how exactly the
fillfactor is used, and in general
- when a page split happens, the process needs to obtain more locks
than with simple insert, which may result in contention
Dne 12.6.2011 21:14, Boszormenyi Zoltan napsal(a):
We recently had a testcase for exercising FILLFACTOR on indexes.
Several (15+) GB raw data arrives daily and must be imported into
the database for analytic purposes, the table is heavily partitioned
and each partition has 5 or 6 indexes. The
Hi,
I've studied the implementation of the btree indexes and how exactly the
fillfactor is used, and in general
- when a page split happens, the process needs to obtain more locks
than with simple insert, which may result in contention with other
processes that modify the index (the same
Yes, I use the same approach, but I'm not aware of any such guideline
related to fillfactor with indexes. Anyway those guidelines need to be
written by someone, so you have a great opportunity ;-)
I did a quick test using your example. As in your test, increasing
values don't get any gain
Yes, I use the same approach, but I'm not aware of any such guideline
related to fillfactor with indexes. Anyway those guidelines need to be
written by someone, so you have a great opportunity ;-)
I did a quick test using your example. As in your test, increasing
values don't get any
What about the index size? How much space do they occupy? Analyze the
table and do this
Of course space is different. That's not the point. The point is: I'm willing
to pay the price for another HD, if that helps with performance. But it doesn't.
The minimal performance difference is
What about the index size? How much space do they occupy? Analyze the
table and do this
Of course space is different. That's not the point. The point is: I'm
willing
to pay the price for another HD, if that helps with performance. But it
doesn't.
The minimal performance difference is
I have an index on a timestamp value that is inserted, for 90%
of the inserts, in increasing order. No updates, no deletes on the
table (appends only).
The bit about increasing order is a red herring here. If you have
no updates, then you can leave the FILLFACTOR alone.
On Mon, May 9, 2011 at 3:32 PM, Leonardo Francalanci m_li...@yahoo.it wrote:
I have an index on a timestamp value that is inserted, for 90%
of the inserts, in increasing order. No updates, no deletes on the
table (appends only).
The bit about increasing order is a red herring here. If
It will be really useful to see some test results where you alter the
fillfactor and report various measurables.
It's not that easy... stressing only the index insertion
speed won't be simple. I would have liked some theory...
The docs seem to imply there are some guidelines, it's
just that
Dne 9.5.2011 17:25, Leonardo Francalanci napsal(a):
It will be really useful to see some test results where you alter the
fillfactor and report various measurables.
It's not that easy... stressing only the index insertion
speed won't be simple. I would have liked some theory...
The docs
Dne 9.5.2011 17:25, Leonardo Francalanci napsal(a):
I know that theory is one thing and real testing another; but I can't
test everything; if there are some (proved?) guidelines I'd like to
use them (example: I'm not going to test that fillfactor in table creation
in my case won't make any
Hi,
the doc pages are somehow cryptic regarding FILLFACTOR.
(well, at least they're cryptic to me, since I don't know a lot
of btree stuff...)
I have an index on a timestamp value that is inserted, for 90%
of the inserts, in increasing order. No updates, no deletes on the
table (appends only).
13 matches
Mail list logo
