Tom Lane wrote:
>Could be. I went back to look at Sam Mason's report about three weeks
>ago, and it definitely seems to explain his issue.
I've just built a patched version as well and it appears to be doing
what I think is the right thing now. I.e. actually picking the
plan with the lower cost.
Dawid Kuroczko wrote:
>work_mem = 102400
>...I tried tweaking cpu_*, work_mem, effective_cache and so on, but without
>any luck.
I'm hoping you didn't tweak it enough! I posted something similar
this a while ago, but haven't since got around to figuring out
a useful test case to send to the list
John A Meinel wrote:
>Why are you using LIMIT without having an ORDER BY?
I'm just exploring the data, trying to figure out what it's like.
>It just seems like this query isn't very useful. As it doesn't restrict
>by animal id, and it just gets 10 randomly selected animals where
>m.mtypeid=0.
Yu
Tom Lane wrote:
>I fooled around trying to duplicate this behavior, without success.
>Can you create a self-contained test case?
I'll try and see if I can put something together, it's probably
going to be early next week though. I wont be able to give you our
data, so I'll be a bit of a headscrat
Hi,
I've just been referred here after a conversion on IRC and everybody
seemed to think I've stumbled upon some strangeness.
The planner (in PG version 8.0.2) is choosing what it thinks is a more
expensive plan. I've got a table of animals (about 3M rows) and their
movements (about 16M rows), a
John A Meinel wrote:
>SELECT t1.id+1 as id_new FROM id_test t1
> WHERE NOT EXISTS
> (SELECT t2.id FROM id_test t2 WHERE t2.id = t1.id+1)
> ORDER BY t1.id LIMIT 1;
This works well on sparse data, as it only requires as many index
access as it takes to find the first gap. The simpler "NO
Merlin Moncure wrote:
>I've already worked out a query using generate_series (not scalable) and
>pl/pgsql. An SQL only solution would be preferred, am I missing
>something obvious?
I would be tempted to join the table to itself like:
SELECT id+1
FROM foo
WHERE id > 0
AND i NOT IN (SELE
Tom Lane wrote:
>It'd be nice to fix this someday, but don't hold your breath ...
Thanks for the response!
Is it even worth me thinking about trying to figure out how to make
the current code do this sort of thing? or is it just not going to
happen with the code as it is?
Sam
---
Hi,
I've got a query that I think the query optimiser should be able
to work it's magic on but it doesn't! I've had a look around and
asked on the IRC channel and found that the current code doesn't
attempt to optimise for what I'm asking it to do at the moment.
Here's a bad example:
SELECT u.
