On Tue, Jul 3, 2012 at 1:31 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Jul 3, 2012 at 12:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
