Re: Commit ab596105b55 - BRIN minmax-multi indexes

On 4/15/21 4:29 PM, Rushabh Lathia wrote:
>
>
> On Thu, Apr 15, 2021 at 7:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com
> <mailto:rushabh(dot)lathia(at)gmail(dot)com>> writes:
> > Commit mentioned in the $subject changed the FirstBootstrapObjectId
> > (transam.h) from 12000 to 13000.  I was trying to understand the
> reason
> > behind this change, but was not able to gather that information.
> Also didn't
> > find anything in the commit message either.
>
> As of right now, genbki.pl <http://genbki.pl>'s OID counter reaches
> 12036, so it's
> pretty clear that 12000 no longer works.  (I have this figure in
> my head because I noted it while working on [1].)  13000 might
> well be an excessive jump though.  Do you have a concrete problem
> with it?
>

Yeah, the bump from 12000 to 13000 might be unnecessarily large. But
considering the bootstrap uses only about 1000 OIDs from the >=13000
range, I don't see this as a problem. Surely we can move the ranges in
the future, if needed?

>
> In EDB Advance Server, it has their own set of system objects.  Due
> to mentioned commit (where it changes the FirstBootstrapObjectId to 13000),
> now system objects exceeding the FirstNormalObjectId.  
>

I haven't checked what the EDBAS does exactly, but how could it hit
16384 because of custom catalogs? I haven't checked what exactly is
EDBAS doing, but surely it does not have thousands of catalogs, right?

It's OK to lower FirstBootstrapObjectId to e.g. 12500 during the merge,
if that solves the issue for EDBAS. As I said, those ranges are mostly
arbitrary anyway, and EDBAS already has catalogs differences.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company