Bruce Momjian wrote:
Heikki, are you going to revise this for 8.4?
Probably not. I have other features I want to work on at the moment.
---
Heikki Linnakangas wrote:
I've brought the GIT patch up-to-date with CVS head. T
Heikki, are you going to revise this for 8.4?
---
Heikki Linnakangas wrote:
> I've brought the GIT patch up-to-date with CVS head. The latest version
> can be found at http://community.enterprisedb.com/git/
>
> I also rera
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
He
Added to TODO:
o Add more logical syntax CLUSTER table ORDER BY index;
support current syntax for backward compatibility
---
Simon Riggs wrote:
> On Sun, 2007-03-11 at 11:22 +, Heikki Linnakangas wrote
Simon Riggs wrote:
> On Sun, 2007-03-11 at 19:06 +0100, Florian G. Pflug wrote:
> > Heikki Linnakangas wrote:
> > > There's a third related term in use as well. When you issue CLUSTER, the
> > > table will be clustered on an index. And that index is then the "index
> > > the table is clustered on
Simon Riggs wrote:
Better thought: say that CLUSTER requires an "order-defining index".
That better explains the point that it is the table being clustered,
using the index to define the physical order of the rows in the heap. We
then use the word "clustered" to refer to what has happened to the
On Sun, 2007-03-11 at 19:06 +0100, Florian G. Pflug wrote:
> Heikki Linnakangas wrote:
> > There's a third related term in use as well. When you issue CLUSTER, the
> > table will be clustered on an index. And that index is then the "index
> > the table is clustered on". That's a bit cumbersome bu
On Sun, 2007-03-11 at 11:22 +, Heikki Linnakangas wrote:
> Gregory Stark wrote:
> >> On Wed, 2007-03-07 at 10:32 +, Heikki Linnakangas wrote:
> >>> I've been thinking
> >>> we should call this feature just Clustered Indexes
> >
> > So we would have "clustered tables" which are tables who
Heikki Linnakangas wrote:
There's a third related term in use as well. When you issue CLUSTER, the
table will be clustered on an index. And that index is then the "index
the table is clustered on". That's a bit cumbersome but that's the
terminology we're using at the moment. Maybe we should to
Gregory Stark wrote:
On Wed, 2007-03-07 at 10:32 +, Heikki Linnakangas wrote:
I've been thinking
we should call this feature just Clustered Indexes
So we would have "clustered tables" which are tables whose heap is ordered
according to an index and separately "clustered indexes" which are
> On Wed, 2007-03-07 at 10:32 +, Heikki Linnakangas wrote:
>> I've been thinking
>> we should call this feature just Clustered Indexes
So we would have "clustered tables" which are tables whose heap is ordered
according to an index and separately "clustered indexes" which are indexes
optimi
On Wed, 2007-03-07 at 10:32 +, Heikki Linnakangas wrote:
> I've been thinking
> we should call this feature just Clustered Indexes
Works for me.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)--
+1
On 3/7/07 6:53 AM, "Grzegorz Jaskiewicz" <[EMAIL PROTECTED]> wrote:
> my only question would be.
> Why isn't that in core already ?
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>cho
my only question would be.
Why isn't that in core already ?
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
I've updated the GIT patch at http://community.enterprisedb.com/git/.
Bitrot caused by the findinsertloc-patch has been fixed, making that
part of the GIT patch a little bit smaller and cleaner. I also did some
refactoring, and minor cleanup and commenting.
Any comments on the design or patch?
On Thu, 2007-02-22 at 12:47 +, Heikki Linnakangas wrote:
> One question that I'm sure someone will ask is do we need this if we
> have bitmap indexes? Both aim at having a smaller index, after all.
> The use cases are quite different; GIT is effective whenever you have
> a table that's reason
I've brought the GIT patch up-to-date with CVS head. The latest version
can be found at http://community.enterprisedb.com/git/
I also reran the CPU bound test cases with the latest patch.
I want this in 8.3 in some form, and I have the time to do any required
changes. If someone wants to see m
On Tue, Dec 12, 2006 at 03:26:32PM -0500, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
> > > The maintain_cluster_order patch is useful by itself, and handles an
> > > existing TODO regarding pulling pages out of WAL in a specified order to
> > > maintain clustering.
> >
> > Pull pages out of
Heikki Linnakangas wrote:
> Jim C. Nasby wrote:
> > On Thu, Dec 07, 2006 at 10:30:11AM +, Heikki Linnakangas wrote:
> >> I've cut a new version of the GIT patch I posted earlier, and collected
> >> all my dispersed todo-lists, post-it notes, performance results,
> >> supplementary patches etc.
Ron Mayer wrote:
Jim C. Nasby wrote:
On usage, ISTM it would be better to turn on GIT only for a clustered
index and not the PK? I'm guessing your automatic case is intended for
SERIAL PKs, but maybe it would be better to just make that explicit.
Not necessarily; since often (in my tables at l
Jim C. Nasby wrote:
> On usage, ISTM it would be better to turn on GIT only for a clustered
> index and not the PK? I'm guessing your automatic case is intended for
> SERIAL PKs, but maybe it would be better to just make that explicit.
Not necessarily; since often (in my tables at least) the data
21 matches
Mail list logo
