-Original Message-
From: Dave Dutcher [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 14, 2007 5:12 PM
To: Rolf Østvik (HA/EXA); pgsql-performance@postgresql.org
Subject: RE: [PERFORM] Problem with grouping, uses Sort and
GroupAggregate, HashAggregate is better(?)
I've got a table with a few million rows, consisting of a single text
column. The average length is about 17 characters. For the sake of
an experiment, I put a trigram index on that table. Unfortunately, %
queries without smallish LIMITs are ridiculously slow (they take
longer than an hour). A
Adam Rich wrote:
Did anybody get a chance to look at this? Is it expected behavior?
Everyone seemed so incredulous, I hoped maybe this exposed a bug
that would be fixed in a near release.
Actually, the planner is only able to do the min()/max() transformation
into order by/limit in the case
Luke Lonergan wrote:
Adam,
This optimization would require teaching the planner to use an index for
MAX/MIN when available. It seems like an OK thing to do to me.
This optimization already exists, albeit for queries that use a single
table.
--
Alvaro Herrera
On Mon, Jan 15, 2007 at 11:16:36AM +0100, Florian Weimer wrote:
Am I missing something? Or are trigrams just a poor match for my data
set? Are the individual strings too long, maybe?
FWIW, I've seen the same results with 8.1.x.
/* Steinar */
--
Homepage: http://www.sesse.net/
Luke Lonergan wrote:
Adam,
This optimization would require teaching the planner to use an index for
MAX/MIN when available. It seems like an OK thing to do to me.
Uhmmm I thought we did that already in 8.1?
Joshua D. Drake
- Luke
-Original Message-
From: [EMAIL PROTECTED]
Does anyone here have positive experiences to relate running
fiberchannel cards on FreeBSD on AMD64? The last time I tried it was
with FreeBSD 4 about 2 years ago and none of the cards I tried could
cross the 32bit memory barrier (since they were all actually 32bit
cards despite plugging into a
