Re: Commit ab596105b55 - BRIN minmax-multi indexes
От | Tomas Vondra |
---|---|
Тема | Re: Commit ab596105b55 - BRIN minmax-multi indexes |
Дата | |
Msg-id | 796cf828-a54b-f041-c350-5fcc09613be7@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Commit ab596105b55 - BRIN minmax-multi indexes (Rushabh Lathia <rushabh.lathia@gmail.com>) |
Список | pgsql-hackers |
On 4/15/21 4:29 PM, Rushabh Lathia wrote: > > > On Thu, Apr 15, 2021 at 7:49 PM Tom Lane <tgl@sss.pgh.pa.us > <mailto:tgl@sss.pgh.pa.us>> wrote: > > Rushabh Lathia <rushabh.lathia@gmail.com > <mailto:rushabh.lathia@gmail.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
В списке pgsql-hackers по дате отправления: