Naz Gassiep <[EMAIL PROTECTED]> writes:
>> Why are hash indexes "obviously" best? In an ideal world with a good
>> implementation maybe, but postgresql b-trees are really quite good.
>>
> Because doing normal queries on a table where there are large text
> blocks is unlikely to be a good idea. E.
On Tue, Jan 08, 2008 at 01:49:53AM +1100, Naz Gassiep wrote:
> >You could always do something like:
> >
> >CREATE INDEX foo ON table((md5(textcol)));
> >
> >Then it will get used in queries like:
> >SELECT * FROM table WHERE md5(textcol) = md5('text');
>
> That's exactly what I was considering doi
On Tue, Jan 08, 2008 at 01:49:53AM +1100, Naz Gassiep wrote:
> I would assume that hash indexes have inbuilt mechanisms for collision
> checking before returning the row as a match. Am I correct in this
> assumption?
Well, they do in the sense that it does the equivalent of:
SELECT * FROM table
On Tue, Jan 08, 2008 at 01:49:53AM +1100, Naz Gassiep wrote:
> Because doing normal queries on a table where there are large text
> blocks is unlikely to be a good idea. E.g.,:
>
> SELECT * FROM table WHERE textcol = 'a 4kb block of text';
I suggest you look at the tsearch stuff instead.
> I wo
Why are hash indexes "obviously" best? In an ideal world with a good
implementation maybe, but postgresql b-trees are really quite good.
Because doing normal queries on a table where there are large text
blocks is unlikely to be a good idea. E.g.,:
SELECT * FROM table WHERE textcol = 'a 4k
On Sat, Jan 05, 2008 at 03:20:54AM +1100, Naz Gassiep wrote:
> Hi there,
>I am creating functionality where there are blocks of text that are
> being stored in the DB and that need to be searched for. No like or
> pattern matching, just a plain old WHERE clause. Obviously, hash indexes
> wou
Hi there,
I am creating functionality where there are blocks of text that are
being stored in the DB and that need to be searched for. No like or
pattern matching, just a plain old WHERE clause. Obviously, hash indexes
would be best here, however I've been warned away from PG's hash
impleme
mark <[EMAIL PROTECTED]> writes:
> I noticed that a large number of log notice messages announcing a
> deadlock being detected together with transactions being aborted
> The tables impacted in the benchmark had HASH indexes. ( only = scans
> were being performed, it seemed a good idea at the tim
Hi,
I have been experimenting with the Apache Benchmarking Tool ( ab ) to
give my demo web site a bit of a hiding. The database backend is
Postgresql 7.1 ( dev from 25/09/00) .
I noticed that a large number of log notice messages announcing a
deadlock being detected together with transactions b
