On Fri, Sep 21, 2012 at 8:31 PM, blambeau <[email protected]> wrote: > Oh sorry. > > Postgresql. The kind of query that is repeating over and over again: > > SELECT "indc"."relname" AS "name", "ind"."indisunique" AS "unique", > "att"."attname" AS "column" FROM "pg_class" AS "tab" INNER JOIN "pg_index" > AS "ind" ON (("ind"."indrelid" = "tab"."oid") AND ('game_games' = > "tab"."relname")) INNER JOIN "pg_class" AS "indc" ON ("indc"."oid" = > "ind"."indexrelid") INNER JOIN "pg_attribute" AS "att" ON (("att"."attrelid" > = "tab"."oid") AND ("att"."attnum" = ANY("ind"."indkey"))) WHERE > (("indc"."relkind" = 'i') AND ("ind"."indisprimary" IS FALSE) AND > ("indexprs" IS NULL) AND ("indpred" IS NULL) AND ("indisvalid" IS TRUE) AND > ("indisready" IS TRUE) AND ("indcheckxmin" IS FALSE)) ORDER BY > "indc"."relname", (CASE "att"."attnum" WHEN "ind"."indkey"[0] THEN 0 WHEN > "ind"."indkey"[1] THEN 1 WHEN "ind"."indkey"[2] THEN 2 WHEN > "ind"."indkey"[3] THEN 3 WHEN "ind"."indkey"[4] THEN 4 WHEN > "ind"."indkey"[5] THEN 5 WHEN "ind"."indkey"[6] THEN 6 WHEN > "ind"."indkey"[7] THEN 7 WHEN "ind"."indkey"[8] THEN 8 WHEN > "ind"."indkey"[9] THEN 9 WHEN "ind"."indkey"[10] THEN 10 WHEN > "ind"."indkey"[11] THEN 11 WHEN "ind"."indkey"[12] THEN 12 WHEN > "ind"."indkey"[13] THEN 13 WHEN "ind"."indkey"[14] THEN 14 WHEN > "ind"."indkey"[15] THEN 15 WHEN "ind"."indkey"[16] THEN 16 WHEN > "ind"."indkey"[17] THEN 17 WHEN "ind"."indkey"[18] THEN 18 WHEN > "ind"."indkey"[19] THEN 19 WHEN "ind"."indkey"[20] THEN 20 WHEN > "ind"."indkey"[21] THEN 21 WHEN "ind"."indkey"[22] THEN 22 WHEN > "ind"."indkey"[23] THEN 23 WHEN "ind"."indkey"[24] THEN 24 WHEN > "ind"."indkey"[25] THEN 25 WHEN "ind"."indkey"[26] THEN 26 WHEN > "ind"."indkey"[27] THEN 27 WHEN "ind"."indkey"[28] THEN 28 WHEN > "ind"."indkey"[29] THEN 29 WHEN "ind"."indkey"[30] THEN 30 WHEN > "ind"."indkey"[31] THEN 31 ELSE 32 END) > > B >
If your app is based on sinatra+sequel, what is coded using sequel ORM? I'm curious about the case with 32 possibilities. What is it for? I would believe this complex SQL might be the issue more than sinatra itself, nor sequel. I do not use postgresql, though I did evaluate it. I use h2 database on jruby, allowing to use prepared statements for such complex business logic. It is compiled once, and it does help gaining some speed. Can you make a small sinatra testcase then? As for DB.tables not being cached, you were talking about memoization then, right? -- Christian -- You received this message because you are subscribed to the Google Groups "sequel-talk" 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/sequel-talk?hl=en.
