From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Hannu Krosing <hannu(at)skype(dot)net>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)acm(dot)org> |
Subject: | Re: vacuum, performance, and MVCC |
Date: | 2006-06-27 16:23:29 |
Message-ID: | 200606271623.k5RGNT427311@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim C. Nasby wrote:
> > > Perhaps my point got lost... in the case where no index keys change
> > > during an update, SITC seems superior in every way to my proposal. My
> > > idea (let's call it Index Tuple Page Consolidation, ITPC) would be
> > > beneficial to UPDATEs that modify one or more index keys but still put
> > > the tuple on the same page. Where SITC would be most useful for tables
> > > that have a very heavy update rate and very few indexes, ITPC would
> > > benefit tables that have more indexes on them; where presumably it's
> > > much more likely for UPDATEs to change at least one index key (which
> > > means SITC goes out the window, if I understand it correctly). If I'm
> > > missing something and SITC can in fact deal with some index keys
> > > changing during an UPDATE, then I see no reason for ITPC.
> >
> > I understood what you had said. The question is whether we want to get
> > that complex with this feature, and if there are enough use cases
> > (UPDATE with index keys changing) to warrant it.
>
> Ideas on how to test a table to see how many tuples would fit this
> criteria?
>
> Or we could just shelve ITPC as a possibility in the future, after we
> see how much the limitations of SITC hurt.
Probably. I am not sure even SITC is a win given the complexity it will
add, but I think it is worth trying. Getting into more complex cases
where chains change indexed values seems like something we could try
later if we have to.
--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2006-06-27 16:26:14 | [Fwd: Re: [Pljava-dev] char with trailing space, PreparedStatement.setObject & SetString] |
Previous Message | Bruce Momjian | 2006-06-27 16:21:40 | Re: vacuum, performance, and MVCC |