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
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 indexes
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
> Sent: 09 August 2002 03:57
> To: Alvaro Herrera
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] CLUSTER and indisclustered
>
>
> If you're looking for something very
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.
...
Chris
> -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
>
&
> > 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
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
> > > 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,
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 an
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;
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 compar
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
se
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
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) w
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 compari
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
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. Th
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 c
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
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 s
20 matches
Mail list logo
