>
> But you're right. With the combined index I can set the granularity
> back to 1000, and empty queries as well as non-empty queries perform
> well. The row estimate is still way off, though.ยจ
Bigger value --> slow analyze. Real maximum is about 200-300. So be carefully.
Regards
Pavel
---
On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
> Alexander Staubo wrote:
> > On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
> >> Although the row-estimate still seems quite high. You might want to
> >> increase it even further (maximum is 1000). If this is a common query,
> >> I'd loo
Alexander Staubo wrote:
On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
Although the row-estimate still seems quite high. You might want to
increase it even further (maximum is 1000). If this is a common query,
I'd look at an index on (user,id) rather than just (user) perhaps.
Actually t
On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
> Although the row-estimate still seems quite high. You might want to
> increase it even further (maximum is 1000). If this is a common query,
> I'd look at an index on (user,id) rather than just (user) perhaps.
Actually that index (with the sa
Alexander Staubo wrote:
On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
Then see if an ALTER TABLE SET
STATISTICS 100 makes a difference.
So it does:
# explain analyze select max(id) from user_messages where user_id = 13604;
QUERY PLAN
--
On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
> Hmm, but with an estimated cost of 3646 (vs.633 for the max(*) which
> uses the wrong index). That explains why it's walking backwards through
> the pkey index, it thinks that it's 8 times cheaper.
[...]
> Have a look at most_common_vals,most_
Alexander Staubo wrote:
On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
Alexander Staubo wrote:
# explain analyze select max(id) from user_messages where user_id = 13604;
QUERY PLAN
On 1/22/08, Richard Huxton <[EMAIL PROTECTED]> wrote:
> Alexander Staubo wrote:
> > # explain analyze select max(id) from user_messages where user_id = 13604;
> >
> > QUERY PLAN
> >
> > ---
Alexander Staubo wrote:
# explain analyze select max(id) from user_messages where user_id = 13604;
QUERY PLAN
--
Result (cost=633
This is on a fresh pg_restore copy that I have additionally vacuumed
and analyzed. These queries, on a table containing 2.8 million rows,
are very fast:
# select count(*) from user_messages where user_id = 13604;
count
---
0
(1 row)
Time: 0.604 ms
# select * from user_messages where use
10 matches
Mail list logo
