From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Removing special case OID generation |
Date: | 2012-02-11 09:23:44 |
Message-ID: | CA+U5nM+AyW6P739Eg+SvNOyuGAcHgw-eHt8gDqrgiKS30w=4XA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 10, 2012 at 10:38 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> On 2/7/12 8:14 AM, Alvaro Herrera wrote:
>>
>> Having one sequence for each toast table could be wasteful though. I
>> mean, sequences are not the best use of shared buffer cache currently.
>> If we could have more than one sequence data in a shared buffer page,
>> things would be different. Not sure how serious this really is.
>
>
> This would actually be an argument for supporting multiple page sizes... too
> bad that's such a beast.
>
> FWIW, from our most complex production database:
>
> cnuapp_prod(at)postgres08(dot)obr=# select relkind, count(*) from pg_class group by
> 1;
> relkind | count
> ---------+-------
> S | 522
> r | 1058
> t | 698
> i | 2894
> v | 221
> c | 12
> (6 rows)
Yeh, I was thinking we would do well to implement cached sequences for
say first 1000 sequences.
That would mean we'd only use a few thousand bytes of memory rather
than 4 MB for your sequences.
Idea would be to make Sequences as fast as OIDs and get rid of the
weird OID code.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Ports | 2012-02-11 09:27:30 | Re: RFC: Making TRUNCATE more "MVCC-safe" |
Previous Message | Noah Misch | 2012-02-11 04:46:02 | Re: RFC: Making TRUNCATE more "MVCC-safe" |