Re: enhanced error fields - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: enhanced error fields
Date
Msg-id CAEYLb_UNxO=+UmWBk2obpJehFQrjpGNKuSNUkD4N3O1kssxVUA@mail.gmail.com
Whole thread Raw
In response to Re: enhanced error fields  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 4 January 2013 17:10, Robert Haas <robertmhaas@gmail.com> wrote:
> I don't really agree with this.  To be honest, my biggest concern
> about this patch is that it will make it take longer to report an
> error.  At least in the cases where these additional fields are
> included, it will take CPU time to populate those fields, and maybe
> there will be some overhead even in the cases where they aren't even
> used (although I'd expect that to be too little to measure).  Now,
> maybe that doesn't matter in the case where the error is being
> reported back to the client, because the overhead of shipping packets
> across even a local socket likely dwarfs the overhead, but I think it
> matters a lot where you are running a big exception-catching loop.
> That is already painfully slow, and -1 from me on anything that makes
> it significantly slower.  I have a feeling this isn't the first time
> I'm ranting about this topic in relation to this patch, so apologies
> if this is old news.

You already brought it up. I measured the additional overhead, and
found it to be present, but inconsequential. That was with Pavel's
version of the patch, that had many more fields then what I've
proposed. Please take a look upthread.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: enhanced error fields
Next
From: Josh Berkus
Date:
Subject: Re: dynamic SQL - possible performance regression in 9.2