| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SSI performance |
| Date: | 2011-02-04 16:55:51 |
| Message-ID: | AANLkTikP_5P+z-p1yLNZA+o8CK2xn7gQA_jtKZWaKer2@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 4, 2011 at 11:07 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 04.02.2011 15:37, Robert Haas wrote:
>>
>> Not sure. How much benefit do we get from upgrading tuple locks to
>> page locks? Should we just upgrade from tuple locks to full-relation
>> locks?
>
> Hmm, good question. Page-locks are the coarsest level for the b-tree locks,
> but maybe that would make sense for the heap.
>
>> It also seems like there might be some benefit to caching the
>> knowledge that we have a full-relation lock somewhere, so that once we
>> get one we needn't keep checking that. Not sure if that actually
>> makes sense...
>
> Well, if you reverse the order of the hash table lookups, that's effectively
> what you get.
I was wondering if it could be cached someplace that was cheaper to
examine, though, like (stabs wildly) the executor scan state.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2011-02-04 17:01:53 | Re: ALTER EXTENSION UPGRADE, v3 |
| Previous Message | Robert Haas | 2011-02-04 16:54:48 | Re: ALTER EXTENSION UPGRADE, v3 |