Robert Haas writes:
> Another option might be to store all the sequences for a particular
> database in a single underlying data file.
We've looked into that before, and found some roadblocks IIRC, though
it probably isn't completely infeasible. See the archives.
regards
On Mon, Feb 13, 2012 at 9:41 AM, Andres Freund wrote:
> On Monday, February 13, 2012 02:08:08 PM Robert Haas wrote:
>> On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs wrote:
>> > Yeh, I was thinking we would do well to implement cached sequences for
>> > say first 1000 sequences.
>>
>> Another optio
On Monday, February 13, 2012 02:08:08 PM Robert Haas wrote:
> On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs wrote:
> > Yeh, I was thinking we would do well to implement cached sequences for
> > say first 1000 sequences.
>
> Another option might be to store all the sequences for a particular
> data
On Mon, Feb 13, 2012 at 8:51 AM, Marti Raudsepp wrote:
> On Mon, Feb 13, 2012 at 15:08, Robert Haas wrote:
>> Honestly, I think the biggest hassle of the OID code is not so much
>> the way they're generated as the way they're stored within heap
>> tuples. I've wondered whether we should go throu
On Mon, Feb 13, 2012 at 15:08, Robert Haas wrote:
> Honestly, I think the biggest hassle of the OID code is not so much
> the way they're generated as the way they're stored within heap
> tuples. I've wondered whether we should go through the system
> catalogs and replace all of the hidden OID co
On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs wrote:
> Yeh, I was thinking we would do well to implement cached sequences for
> say first 1000 sequences.
Another option might be to store all the sequences for a particular
database in a single underlying data file. The current implementation
uses
On Fri, Feb 10, 2012 at 10:38 PM, Jim Nasby 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 s
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 seri
Simon Riggs writes:
> So ISTM that we should just strip out the OID handling code and just
> have a system sequence defined like this
I think this is a pretty poor idea, because the overhead of nextval()
is quite a lot larger than the overhead to get an OID.
regards, tom
Excerpts from Simon Riggs's message of mar feb 07 10:46:09 -0300 2012:
> Recent events have made me notice the OID handling.
>
> AFAICS, OIDs are just a sequence with a max value that fits in a uint.
>
> So ISTM that we should just strip out the OID handling code and just
> have a system sequenc
Recent events have made me notice the OID handling.
AFAICS, OIDs are just a sequence with a max value that fits in a uint.
So ISTM that we should just strip out the OID handling code and just
have a system sequence defined like this
CREATE SEQUENCE _pg_oid
MINVALUE 0
MAXVALUE 4294967296
11 matches
Mail list logo
