Hi, everyone.
Between postres docs, forum posts, previous similar questions answered and
random blogs, I've read as much as I could about why others have had similar
problems in the past before turning to you guys for help, so I really hope
this is not some completely obvious oversight on my part
e drop significantly.
(even more detail: my queries also limit results to 10 approx, so DB quickly
found 10 rows that match location -1, but it took a while to discover there
weren't more than 2 rows with the other value).
Thanks!
Eddy
On Sun, Nov 15, 2009 at 3:33 PM, Tom Lane wrote:
>
y integer
literals? If so, I think it's ok, because it seems like statements C or D
will work well enough when the location distribution is realistic, but I'd
like to be educated for the future :)
Thanks again!
Eddy
On Sun, Nov 15, 2009 at 3:59 PM, Eddy Escardo-Raffo wrote:
> Thanks,
ners (including the postgres planner)
don't do this kind of contingency planning :)
Thanks!
Eddy
On Sun, Nov 15, 2009 at 5:46 PM, Eddy Escardo-Raffo wrote:
> I was using VALUES in my examples to more closely mirror the results of a
> sub-select (I abstracted everything else away and noticed tha
Yeah this kind of thing would probably work. Doing this in java with
separate queries would be easy to code but require multiple round trips.
Doing it as a stored procedure would be nicer but I'd have to think a little
more about how to refactor the java code around the query to make this
happen. T
This is incredibly helpful, Kenneth. I didn't know about the SETOF syntax at
all. This could help minimize the amount of refactoring I need to do.
Thanks!
Eddy
On Mon, Nov 16, 2009 at 12:55 PM, Kenneth Marshall wrote:
> On Mon, Nov 16, 2009 at 12:45:46PM -0800, Eddy Escardo-Raf
e it, you won't
> need any logic changes in your app code (Java or whatever), e.g.
>
> *select where x=:x ..(select .. where . y=:y)
> *
> Becomes
>
> *select myfunction(:x, :y)
> *
>
> On Mon, Nov 16, 2009 at 2:45 PM, Eddy Escardo-Raffo
