On Tue, 2002-08-13 at 09:25, Bruce Momjian wrote:
There is a web page about star joins used a lot in data warehousing,
where you don't know what queries are going to be required and what
indexes to create:
http://www.dbdomain.com/a100397.htm
They show some sample queries, which
I wanted to comment on this bitmapped index discussion because I am
hearing a lot about star joins, data warehousing, and bitmapped indexes
recently.
It seems we have several uses for bitmapped indexes:
Do index lookups in sequential heap order
Allow joining of bitmapped
Tom Lane dijo:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, should we be updating that flag after we CLUSTER instead of
requiring an ANALYZE after the CLUSTER?
Could do that I suppose, but I'm not super-excited about it. ANALYZE is
quite cheap these days (especially in comparison to
Alvaro Herrera [EMAIL PROTECTED] writes:
What if I [try to] extend the grammar to support an additional ANALYZE
in CLUSTER, so that it analyzes the table automatically?
I don't like this -- it seems like bloat. What's the advantage of
CLUSTER foo ON bar ANALYZE;
over
CLUSTER foo ON bar;
Neil Conway dijo:
Alvaro Herrera [EMAIL PROTECTED] writes:
What if I [try to] extend the grammar to support an additional ANALYZE
in CLUSTER, so that it analyzes the table automatically?
I don't like this -- it seems like bloat.
Maybe you are right.
Or maybe just do an analyze of
Or maybe just do an analyze of the table automatically after the
CLUSTERing.
Hmmm... I don't really see the problem with adding a note in the docs
suggesting that users following a CLUSTER with an ANALYZE (...).
ANALYZE is an inexpensive operation (compared to CLUSTER, anyway), so
Christopher Kings-Lynne dijo:
Or maybe just do an analyze of the table automatically after the
CLUSTERing.
Well we have previously had discussions on the topic of adding analyze to
the end of dumps, etc. and the result has always been in favour of keeping
the command set orthogonal
Well we have previously had discussions on the topic of adding
analyze to
the end of dumps, etc. and the result has always been in favour
of keeping
the command set orthogonal and not doing an automatic analyze...
Oh. Sorry for the noise.
I'm trying to look at other things in the
-Original Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]]
Sent: Friday, 9 August 2002 10:21 AM
To: Christopher Kings-Lynne
Cc: Neil Conway; Tom Lane; Bruce Momjian; [EMAIL PROTECTED]
Subject: Re: [HACKERS] CLUSTER and indisclustered
Christopher Kings-Lynne dijo:
Or maybe just do
Neil Conway [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
What if I [try to] extend the grammar to support an additional ANALYZE
in CLUSTER, so that it analyzes the table automatically?
I don't like this -- it seems like bloat.
My reaction exactly.
Hi all,
It occured to me on the plane home that now that CLUSTER is fixed we may
be able to put pg_index.indisclustered to use. If CLUSTER was to set
indisclustered to true when it clusters a heap according to the given
index, we could speed up sequantial scans. There are two possible ways.
1)
Gavin Sherry [EMAIL PROTECTED] writes:
It occured to me on the plane home that now that CLUSTER is fixed we may
be able to put pg_index.indisclustered to use. If CLUSTER was to set
indisclustered to true when it clusters a heap according to the given
index, we could speed up sequantial scans.
On Sat, 3 Aug 2002, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
It occured to me on the plane home that now that CLUSTER is fixed we may
be able to put pg_index.indisclustered to use. If CLUSTER was to set
indisclustered to true when it clusters a heap according to the given
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
It occured to me on the plane home that now that CLUSTER is fixed we may
be able to put pg_index.indisclustered to use. If CLUSTER was to set
indisclustered to true when it clusters a heap according to the given
index, we could speed
Gavin Sherry wrote:
Hi all,
It occured to me on the plane home that now that CLUSTER is fixed we may
be able to put pg_index.indisclustered to use. If CLUSTER was to set
indisclustered to true when it clusters a heap according to the given
index, we could speed up sequantial scans. There
On Sat, 3 Aug 2002, Bruce Momjian wrote:
Gavin Sherry wrote:
Hi all,
It occured to me on the plane home that now that CLUSTER is fixed we may
be able to put pg_index.indisclustered to use. If CLUSTER was to set
indisclustered to true when it clusters a heap according to the given
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, should we be updating that flag after we CLUSTER instead of
requiring an ANALYZE after the CLUSTER?
Could do that I suppose, but I'm not super-excited about it. ANALYZE is
quite cheap these days (especially in comparison to
Gavin Sherry wrote:
Gavin, is that a big win compared to just using the index and looping
through the entries, knowing that the index matches are on the same
page, and the heap matches are on the same page.
Bruce,
It would cut out the index over head. Besides at (1) (above) we would
Gavin Sherry [EMAIL PROTECTED] writes:
On Sat, 3 Aug 2002, Tom Lane wrote:
AFAICT you're assuming that the table is *exactly* ordered by the
clustered attribute. While this is true at the instant CLUSTER
completes, the exact ordering will be destroyed by the first insert or
update :-(. I
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, should we be updating that flag after we CLUSTER instead of
requiring an ANALYZE after the CLUSTER?
Could do that I suppose, but I'm not super-excited about it. ANALYZE is
quite cheap these days (especially in comparison to CLUSTER ;-)). I'd
20 matches
Mail list logo
