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.
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),
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
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 (SELECT
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 NOT IN
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
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
