On Wed, Jun 13, 2012 at 11:55 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@2ndquadrant.com> writes: >> On Wednesday, June 13, 2012 05:18:22 PM Robert Haas wrote: >>> According to my testing, the main cost of an exception block catching >>> a division-by-zero error is that of generating the error message, >>> primarily sprintf()-type stuff. The cost of scanning a multi-megabyte >>> string seems likely to be much larger. > >> True. I ignored that there doesn't have to be an xid assigned yet... I still >> think its not very relevant though. > > I don't think it's relevant either. In the first place, I don't think > that errors occurring "multi megabytes" into a JSON blob are going to > occur often enough to be performance critical. In the second place, > removing cycles from the non-error case is worth something too, probably > more than making the error case faster is worth. > > In any case, the proposed scheme for providing context requires that > you know where the error is before you can identify the context. I > considered schemes that would keep track of the last N characters or > line breaks in case one of them proved to be the one we need. That > would add enough cycles to non-error cases to almost certainly not be > desirable. I also considered trying to back up, but that doesn't look > promising either for arbitrary multibyte encodings.
Oh, I see. :-( Well, I guess I'll have to suck it up, then. -- 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
