| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
| Cc: | simon(at)2ndquadrant(dot)com, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Shared row locking |
| Date: | 2004-12-30 18:36:53 |
| Message-ID: | 27631.1104431813@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> So the question is whether starting by making nbtree more flexible isn't
> the lower hanging fruit...
Certainly not; indexes depend on locks, not vice versa. You'd not be
able to do that without introducing an infinite recursion into the
system design. In any case nbtree is much more heavyweight than we need
for this --- the lock table does not want WAL support for example, nor
REINDEX/VACUUM, nor support for arbitrary index lookup conditions, nor
even multiple datatypes or multiple index columns.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rémi Zara | 2004-12-30 19:23:51 | Re: buildfarm NetBSD/m68k tsearch regression failure |
| Previous Message | Tom Lane | 2004-12-30 18:22:54 | TODO item: make world safe for spaces in build/install paths |