From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Index size |
Date: | 2016-12-11 17:00:50 |
Message-ID: | 22BF390A-7248-4BE7-9930-FD51E8EF4CA8@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Dec 11, 2016, at 08:37, Melvin Davidson <melvin6925(at)gmail(dot)com> wrote:
>
> Yes, I see your point, but the case where the row does not fit into the same block
> would only occur with unlimited field types such as var[], bytea[], etc.
No, that's not correct either. A block can fill up for any number of reasons: Dead tuples, a long HOT chain, or just a lot of data packed into the block. The first UPDATE to a tuple in a block that was populated by continuous INSERTs or a COPY, if the table is using the default fillfactor, will cause the new tuple to be written to a different block, which will cause an index update.
The important thing to remember is that the process you are describing (in which indexes are not updated unless a column involved in the index changes) is an optimization, Heap-Only Tuples. It's a very common optimization, but it's not guaranteed.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2016-12-11 17:43:11 | Re: ora2pg - Java Message Service (JMS) Type |
Previous Message | Melvin Davidson | 2016-12-11 16:37:17 | Re: Index size |