On Tue, Jul 3, 2012 at 1:31 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jul 3, 2012 at 12:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> Yeah, I'm of two minds on that. I thought that it made sense to use
>>>> integer identifiers internally for speed, but now I'm worried that the
>>>> effort to translate back and forth between strings and integers is
>>>> going to end up being more than any speed we might save.
>>>
>>> We do that for nodetags in stored query/expression trees, and I've never
>>> seen any indication that it costs enough to notice. It's definitely a
>>> huge win for anything that changes regularly, which seems like it'll be
>>> a pretty good description of event tags for at least the next few years.
>>
>> Good analogy. In that case, as in what I'm proposing here, we use
>> integers in memory and text on disk.
>
> New patch for that tomorrow. I assume we agree on having a column per
> extra variable,
Yes.
> I'm not sure about already including full support for
> the toplevel one. With some luck I'll have news from you about that
> before sending the next revision of the patch, which then would include
> the int16 evttoplevel[1] column.
No, I'm not asking you to add any more columns right now (in fact,
please do not). But the type of the existing column should change to
text[].
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company