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. T
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 cont
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 page
>
>> 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
> 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
>> 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
> 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 g
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
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"..
> 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
On Mon, May 9, 2011 at 3:32 PM, Leonardo Francalanci 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 y
> > 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.
>
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
