From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Don Baccus <dhogaza(at)pacifier(dot)com> |
Cc: | PostgreSQL HACKERS <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] LZTEXT for rule plan stings |
Date: | 2000-02-26 17:15:19 |
Message-ID: | 27312.951585319@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Don Baccus <dhogaza(at)pacifier(dot)com> writes:
>> What's your basis for asserting the rule is only ~ 1K?
> I looked at the string dumped by pg_dump and it didn't appear to be
> anywhere near 8KB, so I presumed that the actual data stuffed into
> the rule is larger than whatever gets dumped out as the source
> representation.
Yes, the source representation is *vastly* more compact. A single
result column might look like "tab1.product_id" when dumped by pg_dump,
but the nodetree dump looks more like
{ TARGETENTRY
:resdom
{ RESDOM
:resno 1
:restype 23
:restypmod -1
:resname product_id
:reskey 0
:reskeyop 0
:ressortgroupref 0
:resjunk false
}
:expr
{ VAR
:varno 1
:varattno 1
:vartype 23
:vartypmod -1
:varlevelsup 0
:varnoold 1
:varoattno 1
}
}
and (except for not using any excess whitespace) that is exactly what
goes into a rule action string.
As you can see, this is very amenable to compression, especially
when you have a lot of columns in a view.
Someday we might think about using a more compact representation for
stored rules, but there are advantages to using a format that's fairly
easy for a human to examine.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2000-02-26 18:49:14 | Re: [HACKERS] LZTEXT for rule plan stings |
Previous Message | Bruce Momjian | 2000-02-26 15:36:20 | Re: [HACKERS] LZTEXT for rule plan stings |