Re: pg_class.relpages/allvisible probably shouldn't be a int4

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_class.relpages/allvisible probably shouldn't be a int4
Date: 2014-05-30 14:18:42
Message-ID: 20140530141842.GP7857@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund wrote:
> On 2014-05-11 23:30:37 +0200, Andres Freund wrote:

> > Yea. I really don't like to take on such a major project to solve a
> > minor problem.
> > What I am thinking about right now is to expose a 'pg_blocknumber'
> > type. That only does very basic operations and implicitly casts to
> > int64. That's probably a much more handleable problem and it also might
> > give us some more experience with unsigned types. Comments?
>
> As a note towards that: e.g. pageinspect deals with blocknumbers and
> uses int4 for that. That makes accessing the higher blocks really
> awkward...

Sounds like pg_blocknumber could be a good idea, but I wouldn't add the
bigint implicit casts to int64. We might enlarge BlockNumber to
unsigned 64 bits in the future -- we will regret the implicit casts to
signed int64 then. Anyway it's not like implicit casts will get us any
extra functionality. We can just add + and - operators, and that should
cover 99% of what people would initially want ...

Now, adding casts FROM int32 and int64 to pg_blocknumber doesn't sound
bad. (Maybe have them error out if the value is negative?)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2014-05-30 14:55:18 Re: SP-GiST bug.
Previous Message Claudio Freire 2014-05-30 13:36:37 Re: Extended Prefetching using Asynchronous IO - proposal and patch