Quoth Petite Abeille , on 2014-02-03 23:49:14 +0100:
> Not directly related to your question, but… why oh why do people
> molest their queries by gratuitously and pointlessly aliasing
> perfectly good table name to meaningless random one letter codes?!?
> Masochism?
On Mon, 3 Feb 2014 23:49:14 +0100
Petite Abeille wrote:
> > I have a query
>
> Not directly related to your question, but? why oh why do people
> molest their queries by gratuitously and pointlessly aliasing
> perfectly good table name to meaningless random one letter
> Not directly related to your question, but… why oh why do people molest their
> queries by
> gratuitously and pointlessly aliasing perfectly good table name to
> meaningless random
> one letter codes?!? Masochism?
lol, you're not wrong.
This code is used in Python, and we are strict
> No. It appears to be a correlated subquery. It depends on the current row
> of the "d" table (diffset) because of the "ON r.guid_id=did" term and thus
> has to be reevalatued for every row of the "d" table.
Richard,
After a closer look, the subquery was useless and needed to be removed.
On Feb 3, 2014, at 11:30 PM, Joseph L. Casale wrote:
> I have a query
Not directly related to your question, but… why oh why do people molest their
queries by gratuitously and pointlessly aliasing perfectly good table name to
meaningless random one letter codes?!?
On Mon, Feb 3, 2014 at 5:30 PM, Joseph L. Casale
wrote:
> I have a query where if I hard code the results of the nested SELECT
> DICTINCT to a few
> static values, it completes very fast. Leaving the select causes this
> query to slow down
> badly. Running an explain
I have a query where if I hard code the results of the nested SELECT DICTINCT
to a few
static values, it completes very fast. Leaving the select causes this query to
slow down
badly. Running an explain query plan wasn't obvious with my weak sql experience.
Is the nested query not evaluated only
7 matches
Mail list logo