From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add support for logging the current role |
Date: | 2011-01-15 03:15:59 |
Message-ID: | 17181.1295061359@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> In any case, if the GUC representation is a list of field names, I think
>> the POLA demands that the system honor the list order.
> Agreed. That puts us back into the question of how to make it
> efficient. My best thought at the moment, which doesn't strike me as
> particularly efficient, is to build an array of the columns as enum's
> and then have loop through the array and use a switch() on the enum.
Yeah, an array or list of integer codes was what I was thinking too.
> At least it's all integer-based there then and we're not calling
> strcmp() for every field or strchr to find the next field, but
> couldn't we do better?
I really doubt that the cycles spent in the loop + switch are going to
amount to anything at all, compared to the cycles involved in formatting
each field and then pushing it through the CSV logic. Not to mention
the I/O costs of sending the string somewhere afterwards.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2011-01-15 03:20:39 | Re: Add support for logging the current role |
Previous Message | Noah Misch | 2011-01-15 03:13:05 | Re: Snapshot synchronization, again... |