i'm just wondering for performance over-the-wire from the bandwidth alone...
I see great, DBA toubleshooting friendly stuff like:
SELECT table_one.column_one AS table_one_column_one FROM table_one ;
but that could be...
SELECT t1.column_1 AS t1_column_1 FROM table_one t1;
or even
On Jan 20, 2014, at 4:32 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
i'm just wondering for performance over-the-wire from the bandwidth alone...
I see great, DBA toubleshooting friendly stuff like:
SELECT table_one.column_one AS table_one_column_one FROM table_one ;
but
so wow. that's really neat. amazingly neat.
and yeah, i'm just looking for ways to get some more performance out of a
few boxes , so we don't have to add another box. trying to cut the fat here
and there -- and noticed some very verbose sql. wondering if losing it will
get 1-2% more out of
On Jan 20, 2014, at 5:23 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
2. it doesn't affect the label/aliasing on the table, just the column . ie,
SELECT mytable.id AS _1 FROM mytable
not
SELECT _t1.id AS _1 FROM mytable _t1
that it can’t do. an Alias is a very
sorry , should have been more clear. i'm trying to get some more juice out
of of the database server. it is streaming sql nonstop. the webservers
are doing fine, and are simple to cluster out.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
i know. my point was, get rid of a few SQL statements altogether instead of
trying to shrink the char counts in the ones you have….
if you really want, you can build a cursor_execute() event that does rewriting
at that level.
as far as the coerce_from_config theres a ticket somewhere to
i couldn't find anything on trac earlier for `coerce_from_config`
i'd be happy to whip up a patch for the .8 branch that
updates coerce_from_config to support all the create_engine kwargs. i have
no idea how to do that for the .9 branch though.
my sql is pretty optimized as is, with
