Re: Replication Syatem
От | Pavan Deolasee |
---|---|
Тема | Re: Replication Syatem |
Дата | |
Msg-id | 2e78013d0804300915u32b9a190k86496c02dba7babd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Replication Syatem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Replication Syatem
|
Список | pgsql-performance |
On Wed, Apr 30, 2008 at 8:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Pavan Deolasee" <pavan.deolasee@gmail.com> writes: > > That's weird. With that fillfactor, you should have a very high > > percentage of HOT update ratio. It could be a very special case that > > we might be looking at. > > He's testing > It's "She" :-) Oh yes. Apologies if I sounded harsh; did not mean that. I was just completely confused why she is not seeing the HOT updates. > >> update table1 set delta1 = 100 where code/1000000 =999; > > so all the rows being updated fall into a contiguous range of "code" > values. If the table was loaded in such a way that those rows were > also physically contiguous, then the updates would be localized and > would very soon run out of freespace on those pages. > Yeah, that seems like the pattern. I tested with the similar layout and a fill factor 80. The initial few bulk updates had comparatively less HOT updates (somewhere 20-25%), But within 4-5 iterations of updating the same set of rows, HOT updates were 90-95%. That's because after few iterations (and because of non-HOT updates) the tuples get scattered in various blocks, thus improving chances of HOT updates. I guess the reason probably is that she is using fill factor for indexes and not heap, but she hasn't yet confirmed. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
В списке pgsql-performance по дате отправления: