| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_sequence catalog |
| Date: | 2016-08-31 17:08:45 |
| Message-ID: | 20160831170845.u4qah25ymbwyora4@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2016-08-31 12:53:30 -0400, Tom Lane wrote:
> Improving on the space wastage is exactly the point IMO. If it's still
> going to be 8k per sequence on disk (*and* in shared buffers, remember),
> I'm not sure it's worth all the work to change things at all.
A separate file is a heck lot more heavyweight than another 8 kb in an
existing file.
> Another idea would be to have nominally per-sequence LWLocks (or
> spinlocks?) controlling nextval's nontransactional accesses to the catalog
> rows, but to map those down to some fixed number of locks in a way similar
> to the current fallback implementation for spinlocks, which maps them onto
> a fixed number of semaphores. You'd trade off shared memory against
> contention while choosing the underlying number of locks.
If we could rely on spinlocks to actually be spinlocks, we could just
put the spinlock besides the actual state data... Not entirely pretty,
but probably pretty simple.
- Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2016-08-31 17:25:43 | Re: pg_sequence catalog |
| Previous Message | Claudio Freire | 2016-08-31 17:08:23 | Re: Patch: Write Amplification Reduction Method (WARM) |