L.S.
Could anybody explain why the planner is doing what it is doing?
What could I do to make it easier to choose a better plan?
*
Summary
*
On a freshly vacuum/analysed pair of tables with 7389 and 64333 records, this:
select id from location where id not in (select location_
Wow,
The effectiveness of the pgsql mailinglists never ceases to amaze me.
Default sort mem it was, I guess I'd simply been to cautious with this
per-client setting.
Stephan & Tom : thanks!
--
Best,
Frank.
---(end of broadcast)---
TI
Hi all,
I noticed the following. Given two tables, just simply articles and their
packages:
article(id int)
package( id int, article_id int, amount)
When taking the minimum package for articles given some constraint on the
article table
select
article.
> Obviously this is on toy tables
The query is simplified, yes. But the data in the tables is real, albeit
they're not that large.
> You're misinterpreting it.
I might very well be ;)
But I also get the feeling I didn't explain to you well enough what I meant...
> Without the group by, the pla
> We don't attempt to make every possible inference (and I don't think
> you'd like it if we did).
I wasn't really asking you to, either ;))
Just trying to achieve a more in-depth understanding of the way things work.
> This example doesn't
> persuade me that it would be worth expending the cycl
Hi,
I'm seeing the following behaviour with the table and functions given below:
db=# insert into f select * from full_sequence(1, 1000);
INSERT 0 1000
Time: 197,507 ms
db=# insert into f select * from full_sequence(1, 1000);
INSERT 0 1000
Time: 341,880 ms
db=# insert into f select * from full_se
Obviously,
this part of tr_f_def():
**
-- delete the contents
-- delete from f;
IF EXISTS (SELECT 1 FROM f) THEN
DELETE FROM F;
VACUUM F;
END IF;
**
Hi Josh,
> > It seems in this case the time needed for a single deferred trigger
> > somehow depends on the number of dead tuples in the table
After further investigation I think I have a better grasp of what's going on.
The thing biting me here is indeed the 'delete from' on a table with a numb
L.S.
I'm noticing a difference in planning between a join and an in() clause,
before trying to create an independent test-case, I'd like to know if there's
an obvious reason why this would be happening:
=> the relatively simple PLPGSQL si_credit_tree() function has 'ROWS 5' in
it's definition
> > I'm noticing a difference in planning between a join and an in() clause,
> > before trying to create an independent test-case, I'd like to know if
> > there's
> > an obvious reason why this would be happening:
>
> Is the function STABLE ?
Yep.
For the record, even changing it to immutable doe
> > db=# explain analyse
> > select sum(base_total_val)
> > from sales_invoice
> > where id in (select id from si_credit_tree(8057));
>
> Did you check whether this query even gives the right answer?
You knew the right answer to that already ;)
> I think you forgot the alias foo(i
11 matches
Mail list logo
