Re: Do we need use more meaningful variables to replace 0 in catalog head files?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Jan de Visser <jan(at)de-visser(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Hao Lee <mixtrue(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Date: 2016-11-13 14:48:25
Message-ID: d732def2-6e1d-6dad-0465-728641bcb690@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/13/2016 04:54 AM, Andres Freund wrote:
> On 2016-11-12 12:30:45 -0500, Andrew Dunstan wrote:
>>
>> On 11/11/2016 11:10 AM, Tom Lane wrote:
>>> boolin: OID=1242 proname=boolin proargtypes="cstring" prorettype=bool
>>> boolin: prosrc=boolin provolatile=i proparallel=s
>>>
>>>
>>
>> I have written a little perl script to turn the pg_proc DATA lines into
>> something like the format suggested. In order to keep the space used as
>> small as possible, I used a prefix based on the OID. See attached result.
>>
>> Still plenty of work to go, e.g. grabbing the DESCR lines, and turning this
>> all back into DATA/DESCR lines, but I wanted to get this out there before
>> going much further.
>>
>> The defaults I used are below (commented out keys are not defaulted, they
>> are just there for completeness).
> In the referenced thread I'd started to work on something like this,
> until other people also said they'd be working on it. I chose a
> different output format (plain Data::Dumper), but I'd added the parsing
> of DATA/DESCR and such to genbki.
>
> Note that I found that initdb performance is greatly increased *and*
> legibility is improvided, if types and such in the data files are
> expanded, and converted to their oids when creating postgres.bki.

Yeah, I have the type name piece, it was close to trivial. I just read
in pg_type.h and stored the names/oids in a hash.

Data::Dumper is too wasteful of space. The thing I like about Tom's
format is that it's nice and concise.

I'm not convinced the line prefix part is necessary, though. What I'm
thinking of is something like this:

PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=1
rettype=bool argtypes="cstring" src=boolin );

Teaching Catalog.pm how to parse that and turn the type names back into
oids won't be difficult. I already have code for the prefix version, and
this would be easier since there is an end marker.

I'd actually like to roll up the DESCR lines in pg_proc.h into this too,
they strike me as a bit of a wart. But I'm flexible on that.

If we can generalize this to other catalogs, then that will be good, but
my inclination is to handle the elephant in the room (pg_proc.h) and
worry about the gnats later.

>
> I basically made genbki/catalog.pm accept text whenever a column is of
> type regtype/regprocedure/. To then make use of that I converted a bunch
> of plain oid columns to their their reg* equivalent. That's also nice
> for just plain qureying of the catalogs ;)
>
> I don't think the code is going to be much use for you directlky, but it
> might be worthwhile to crib some stuff from the 0002 of the attached
> patches (based on 74811c4050921959d54d42e2c15bb79f0e2c37f3).

Thanks, I will take a look.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2016-11-13 15:45:53 Physical append-only tables
Previous Message Christian Convey 2016-11-13 14:14:09 Re: Tackling JsonPath support