| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Patch to improve performance of replay of AccessExclusiveLock |
| Date: | 2017-03-07 17:04:12 |
| Message-ID: | 20170307170412.p5otd6fhpsph6jcc@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2017-03-08 00:15:05 +1300, David Rowley wrote:
> -static List *RecoveryLockList;
> +/*
> + * RecoveryLockTable is a poor man's hash table that allows us to partition
> + * the stored locks. Which partition a lock is stored in is determined by the
> + * xid which the lock belongs to. The hash function is very simplistic and
> + * merely performs a binary AND against the final 0-based partition number.
> + * Splitting into partitions in this way avoids having to look through all
> + * locks to find one specific to a given xid.
> + */
> +static List **RecoveryLockTable;
Why are we open coding this? That strikes me as a bad plan...
Regards,
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-03-07 17:27:27 | Re: Partitioned tables and relfilenode |
| Previous Message | Dilip Kumar | 2017-03-07 17:00:24 | Re: Proposal : Parallel Merge Join |