-0700, Graham Davis wrote:
I have a question about index growth.
The way I understand it, dead tuples in indexes were not reclaimed by
VACUUM commands in the past. However, I've read in a few forum posts
that this was changed somewhere between 7.4 and 8.0.
There was a change to in
rking when I run a VACUUM? Is it
suppose to work?
--
Graham Davis
Refractions Research Inc.
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
(users_id, id) - but I really don't like adding
more indices to the transaction table.
---(end of broadcast)---
TIP 6: explain analyze is your friend
--
Graham Davis
Refractions Research Inc.
[EMAIL PROTECTED]
-
Not many. It fluctuates, but there are usually only ever a few hundred
at most. Each assetid has multi-millions of positions though.
Mark Lewis wrote:
Hmmm. How many distinct assetids are there?
-- Mark Lewis
On Tue, 2006-10-03 at 14:23 -0700, Graham Davis wrote:
The "summary
there were far fewer distinct
assetid values than rows in the main table, and would get slow if you
commonly delete rows from the main table or decrease the value for ts in
the row with the highest ts for a given assetid.
-- Mark Lewis
On Tue, 2006-10-03 at 13:52 -0700, Graham Davis wrote:
Thanks T
wrote:
Graham Davis <[EMAIL PROTECTED]> writes:
How come an aggreate like that has to use a sequential scan? I know
that PostgreSQL use to have to do a sequential scan for all aggregates,
but there was support added to version 8 so that aggregates would take
advantage of indexes.
can use an index and the following can't:
SELECT assetid, max(ts) AS ts
FROM asset_positions
GROUP BY assetid;
--
Graham Davis
Refractions Research Inc.
[EMAIL PROTECTED]
Chris Browne wrote:
[EMAIL PROTECTED] (Graham Davis) writes:
40 seconds is much too slow for this query to run an
Also, the multikey index of (assetid, ts) would already be sorted and
that is why using such an index in this case is
faster than doing a sequential scan that does the sorting afterwards.
Graham.
Chris Browne wrote:
[EMAIL PROTECTED] (Graham Davis) writes:
Adding DESC to both columns in
een when I removed the
GROUP BY clause). Any tips?
Graham.
Chris Browne wrote:
[EMAIL PROTECTED] (Graham Davis) writes:
Adding DESC to both columns in the SORT BY did not make the query use
the multikey index. So both
SELECT DISTINCT ON (assetid) assetid, ts
FROM asset_positions ORDER BY a
DESC;
use the same query plans and both do sequential scans without using either the
(assetid, ts) or (ts) indexes. Any other ideas on how to make this query use
an index? Thanks,
--
Graham Davis
Refractions Research Inc.
[EMAIL PROTECTED]
On Wed, Sep 27, 2006 at 20:56:32 +,
Graham
10 matches
Mail list logo
