| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Teodor Sigaev" <teodor(at)sigaev(dot)ru>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Nikhil S" <nikhil(dot)sontakke(at)enterprisedb(dot)com> |
| Subject: | Re: HOT for PostgreSQL 8.3 |
| Date: | 2007-02-09 16:11:58 |
| Message-ID: | 1171037518.22638.73.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2007-02-09 at 10:17 -0500, Tom Lane wrote:
> Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> >> Implementing the "replace these TIDs" operation atomically would be
> >> simple, except for the new bitmap index am. It should be possible there
>
> > That isn't simple (may be, even possible) from GIN.
>
> I suspect that those pushing this idea only care about btrees anyway,
> so one possible answer is that HOT is only possible when the table has
> only btree indexes --- or at least, only indexes of AMs that support the
> replace-these-TIDs operation. (Yet another pg_am flag...)
Well, thats me. Yes, I think b-trees-only is acceptable.
Realistically, very frequent updating and full text indexing are easily
separable use cases, at least into separate tables.
HOT should be of use in Data Warehousing applications also, when summary
tables are maintained alongside detailed data, but that also sounds like
HOT and bitmap indexes would be separable at the table level without
difficulty.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2007-02-09 16:15:28 | Re: possible TODOs |
| Previous Message | Andrew Dunstan | 2007-02-09 15:45:44 | possible TODOs |