On Fri, 2 Apr 2004, Tom Lane wrote:
> Could we see EXPLAIN ANALYZE output?
Certainly, but that's going to take a little time (as the ANALYZE causes
it to run the actual query, which I only just discovered), so may have to
wait until Monday if I don't get time to finish it this afternoon.
--
Cl
On Fri, Apr 02, 2004 at 01:00:45 +0200,
Palle Girgensohn <[EMAIL PROTECTED]> wrote:
>
> Is it always bad to create index xx on yy (field1, field2, field3);
>
> I guess the problem is that the index might often grow bigger than the
> table, or at least big enough not to speed up the queries?
O
Clive Page <[EMAIL PROTECTED]> writes:
> This executes, it need hardly be said, a whole lot faster.
Could we see EXPLAIN ANALYZE output?
The estimated costs for the two cases are nearly the same, which says to
me that there's something wrong with the cost model for r-tree lookups,
but I don't kno
I am trying to do a spatial join between two tables each of which has a
column of type BOX called ERRBOX, with R-TREE indices created on both.
The smaller table, xmm1, has 56,711 rows,
the larger one, twomass, has 177,757,299 rows.
The most efficient way to join these is to do a sequential s
another thing that I have all over the place is a hierarchy:
index on grandfather_table(grandfather)
index on father_table(grandfather, father)
index on son_table(grandfather, father, son)
almost all of my indices are composite. Are you thinking about composite
indices with low cardinality leading
