Varieur: Tum: and cross joins have nothing to do with the implicit join form.

Knack: Okay. a question. Is there a better way to compute the total?

Arzo: It’s totally disjoint from the other inner join

Varieur: Tum: without window functions, a cross join is fine

Himmelmann: What’s bad about using./

Varieur: Tum: always use a specific ON clause instead.

Pemble: But if the tables have the column names as I specify in the using clause, how is that ambiguous

Varieur: Tum: for other readers.

Gerteisen: How is a join b on a.x = b.x less ambiguous than a join b usingx?

Buckley: To me they look really equivalent, except the latter is easier to write

Dillmore: And the output column for x will be one column instead of the confusing two columns that have the same content

Auman: Varieur: I updated the gist

Whatoname: Https://gist.github.com/tummykung/81b86e41e6fb2b3edc21

Humphries: But still I don’t quite understand why the indices of ps_cl***_instr didn’t get picked up

Varieur: Tum: because you have nothing in the WHERE clause to filter those rows, so the entire table is scanned

Wilcoxson: Is it better if I filter first then?

Varieur: Tum: if you can filter down rows from that table with the WHERE clause, it’s better

Cuizon: Varieur: ok I tried. The query time goes up from 15 s to 50 s. See relevant command at https://gist.github.com/tummykung/81b86e41e6fb2b3edc21

Horuath: Varieur: it seems the bottleneck part is join

Vonstein: Hey ladies, I have some compressed tables, would it be possible to know what the compressed vs. real size for those are? I want to know if it’s worth it.

Dipiazza: It seems indexing columns used in join doesn’t help

Wickings: But I’m not sure what else I could do to speed up join

Varieur: Tum: might be able to force the index

Manchester: I’m trying to get help with using sql workbench for the first time. when i add a column to a table, and check PK, the explantion mark to indicake primary key is not displaying. it’s also giving me gried about the data type. i selected INT

Visco: I think it has something to do with setting the primary keys as indexed

Wischman: Gummi_: MySQL Workbench: http://mysql.com/products/tools/workbench/ it has its own chat channel #workbench

Kotrba: To make the primary key indexed, should the default index name “Primary” be changed?

Manross: Gummi_: a primary key is by definition an index. only one allowed per table, values must be unique and not null

Manross: Gummi_: in mysql, index == key

Varieur: Tum_: and remove the single-column index on CRSE_ID

Geffre: In phpMyAdmin “Structure”/”Relation view” I see some relations in our DB despite our tables are MyISAM. But in MyISAM there are no relations! I am confused

Manross: Porton: see /topic, we don’t support phpmyadmin

Manross: Porton: what do you think relation means?

Wierman: Manross: I thought they are essentially the same as foreign keys, but now I am confused

Manross: Porton: to have a FOREIGN KEY CONSTRAINT, both tables need to be innodb.

Bellair: Manross: I know it, it is the reason why I didn’t expect to see relations for a MyISAM table

Manross: Porton: I have no idea what pma is trying to do. you might ask #phpmyadmin

Mahmood: I’m thinking about storing base64-encoded images in a table, but I’m not sure the best data type to use. I was thinking BLOB, but I’m not sure. each image may be up to 10MB or so before base64 encoding; not sure if that adds to the size or not

Kouba: Https://gist.github.com/tummykung/9d91241c9b8332d4453e

Heavner: I already forced ps_cl***_instr to use a desired index, but it still doesn’t pick up

Lerer: X86: BLOB is 65k max. 10MB would require LONGBLOB