On Sat, Nov 7, 2009 at 3:02 PM, Michael Bayer <[email protected]> wrote: > > > On Nov 7, 2009, at 1:30 PM, Jon Nelson wrote: > >> File "pg8000/protocol.py", line 121, in serialize >> val = struct.pack("!i", len(val) + 4) + val >> UnicodeDecodeError: 'ascii' codec can't decode byte 0x8d in position >> 3: ordinal not in range(128) > > make sure you're on the latest tip of pg8000, which these days seems > to be at http://github.com/mfenniak/pg8000/tree/trunk . It also > adheres to the client encoding of your PG database, which you should > make sure is on utf-8.
Ah. I was running the latest /released/ version - I generally avoid running 'tip/HEAD/whatever' except during testing. Since I don't expect pg8000 to have any substantially different behavior, it's probably not even worth the effort. <snip/> > I'm surprised that sqlite, per your > observation, parses an INSERT statement and re-renders it with > multiple VALUES clauses ? very surprising behavior. I'm not sure I said that - I certainly didn't intend that. Ultimately, the IPC costs associated with each set of bind params (one per row) just murders psycopg2 when compared to sqlite. There isn't any sqlite RPC per-se, since it's always local. I can only assume that sqlite defers locking the database until the start of a transaction, and since sqlite isn't multi-writer aware the overhead of doing so is minimal. I wasn't comparing sqlite and postgresql per se - there isn't much of a comparison in my mind once you start needing all of the features, stability, and power that postgresql brings. However, I was disappointed to see that psycopg2 is not making use of the (postgresql 8.2 and newer) multi-bind param INSERT stuff, as this ultimately reduces the IPC overhead to a very small amount. The cost of a single call to postgresql might be small, but when you multiply it by hundreds of thousands or millions it suddenly becomes a deciding factor in some situations. -- Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
