Re: That killer 3rd join...
От | Oliver Smith |
---|---|
Тема | Re: That killer 3rd join... |
Дата | |
Msg-id | 20000907011110.A31180@kfs.org обсуждение исходный текст |
Ответ на | Re: That killer 3rd join... (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: That killer 3rd join...
|
Список | pgsql-general |
> OTOH, I'm not 100% sure what you're trying to get out > from this query, I'd have expected that it would be, using > these metals on this stone gives you this result, but since > the types of jewelery I get are different on the same row > of output, I'm a little confused. Each stone gives a specific set of attributes, but combining it with silver & plat gives one type of jewellery, while gold & electrum produce a different type. The reason for including this is so that a chart can be produced which shows what attributes each stone modifies, how much those attributes are modified for each stone+metal combo, and what type of jewellery is produced in the combo. See http://www.kfs.org/~oliver/eq/jewellery.jsp to see the chart itself. As my own side note, on Postgres 7.0.2, I at one point tried creating a view which said CREATE VIEW silver_view AS SELECT * from jcombo_query WHERE metal_uid = 1 ; and so on for elec, gold, plat. And then used these to simplify the main query. This caused Postgres to go away permanently, and I had to manually delete the database. And the original query was so slow, that I decided to, for the time being, do a SELECT * INTO jewellery FROM metals_query ORDER BY stone_uid ; Ol -- If at first you don't succeed, skydiving is not for you...
В списке pgsql-general по дате отправления: