On Feb 26, 2009, at 11:02 AM, Grzegorz Jaśkiewicz wrote:
looks like you completely misunderstood my question.
I'm not surprised. What do you expect with random capitalisation, random table alias names and random indentation combined with queries getting wrapped by the mailing-list software? With some proper formatting and meaningful alias-names some people might actually understand what you're trying to get at. You're not exactly helping here. You're the one who's asking a question, it's your responsibility that we can understand your problem.
With respect to your "original" naming scheme... indeed, foo, bar and baz aren't the most elaborate names for tables or aliases, but at least we are used to them. More meaningful names are still preferred of course. Those meta-table-names are better reserved for theoretical situations where no meaningful names are available. I'm pretty sure in your case more meaningful names are easy to come up with, so please do.
First of all, I wonder why the same query divided up in half - and using temporary table works as expected, and with everything together doesn't. And about rand(), it was tested on large enough set of runs, that I don't think it is to blame.
Well, as hard as I try reading that SQL, I lose track somewhere halfway due to the above issues. I don't feel like rewriting your queries to make them readable (I have no obligation to do that, after all), and even then I'm not sure what you're trying to show with them. They do look overly complicated, but without knowing their purpose it is kind of hard to see what you're trying to tell.
The queries do everything I wanted it to do, and - no - doing it in software is just baaad, and doesn't do.
I figured you were complaining about the performance, hence I gave you a better performing solution. Apparently that wasn't what your question was about, but it's still good advice IMO.
Your comment about the solution I gave you borders on insulting. The method I showed you isn't any worse than your solution using temp tables, as both solutions move logic to the application. It's hardly any code in the application in either case, I wonder why you'd be so set against using a cursor that you'd prefer a much more inefficient solution that uses about as much application-side code as what I proposed. Besides, I showed that it's possible to put the logic in the database, but apparently you didn't bother to read that far.
(What argument are you trying to make there anyway? X is bad and just doesn't do... How is that an argument? - That's a rhetorical question, it isn't).
Goodness, look at all the time I wasted trying to get a proper question out of you...
Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:737,49a7359f129748797120425! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
