On Tuesday, February 12, 2019 at 6:14:44 PM UTC-5, Mike Bayer wrote:
>
> as you know I prefer making things possible to making things assumed
> :) , because in the latter case, I have to keep attending to those
> assumptions as they change. The whole "rewrite EXPANDING" part of
> defaultdialect should be expandable. I think maybe an event hook in
> that area might be helpful, not sure.
Of course. There are a lot of ways this could be handled too - as a
plugin, a recipe, etc... but wanted to start a dialog on it.
I didn't know about the VALUES syntax performance difference, and It would
be very useful to turn the VALUES syntax on/off on a per query option when
working on optimizations.
>From a few tests, these all generate the same results, but have VERY
different performance, plans and executions depending on the query:
WHERE items.parent_id IN (1, 2, 3)
WHERE items.parent_id IN (VALUES (1), (2), (3))
WHERE items.parent_id = ANY (VALUES (1), (2), (3))
WHERE items.parent_id = ANY (ARRAY[1, 2, 3])
While SqlAlchemy allows us to edit the queries to emit each of these, it
would be incredibly useful to achieve all the forms through a single
operator and toggling a kwarg to influence how the sql is generated.
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
