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 64b
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 P
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.
This optimization already exists, albeit for queries that use a single
table.
--
Alvaro Herrera
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 c
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
> -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(?)
>
> > --
