Tom Lane <[EMAIL PROTECTED]> writes:
> However: what about storing the things in hashcode order? Ordering uint32s
> doesn't seem like any big conceptual problem.
>
> I think that efficient implementation of this would require explicitly
> storing the hash code for each index entry, which we don'
Tom Lane wrote:
I have a gut reaction against that: it makes hash indexes fundamentally
subservient to btrees.
I wouldn't say "subservient" -- if there is no ordering defined for the
index key, we just do a linear scan.
However: what about storing the things in hashcode order? Ordering uint32s
d
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> On the other hand, once you reach the target index page, a hash index
>> has no better method than linear scan through all the page's index
>> entries to find the actually wanted key(s)
> I wonder if it would be possible to store the key
Tom Lane wrote:
On the other hand, once you reach the target index page, a hash index
has no better method than linear scan through all the page's index
entries to find the actually wanted key(s)
I wonder if it would be possible to store the keys in a hash bucket in
sorted order, provided that the
Neil Conway <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>>> No, hash joins and hash indexes are unrelated.
>> I know they are now, but does that have to be the case?
> I mean, the algorithms are fundamentally unrelated. They share a bit of
> code such as the hash functions themselves, but t
Iron Systems has a fair selection of opteron machines, up to 4 way.
The one I have has Tyan guts.
On May 9, 2005, at 4:10 PM, Anjan Dave wrote:
The DP+DC isn't available yet, from Sun. Only QP+DC is, for which the
bid opens at 38k, that is a bit pricey -:)
-Original Message-
From: Willia
Jim C. Nasby wrote:
> On Tue, May 10, 2005 at 02:38:41AM +1000, Neil Conway wrote:
> > Jim C. Nasby wrote:
> > >Having indexes that people shouldn't be using does add confusion for
> > >users, and presents the opportunity for foot-shooting.
> >
> > Emitting a warning/notice on hash-index creation
Jim C. Nasby wrote:
>> No, hash joins and hash indexes are unrelated.
I know they are now, but does that have to be the case?
I mean, the algorithms are fundamentally unrelated. They share a bit of
code such as the hash functions themselves, but they are really solving
two different problems (dis
*Note: * Testing has shown PostgreSQL's hash indexes to perform no
better than B-tree indexes, and the index size and build time for hash
indexes is much worse. For these reasons, hash index use is presently
discouraged.
May I know for simple "=" operation query, for "Hash index" vs.
"B-tree"
[EMAIL PROTECTED] writes:
> How can i know a capacity of a pg database ?
> How many records my table can have ?
> I saw in a message that someone have 50 000 records it's possible in a table ?
> (My table have 8 string field (length 32 car)).
> Thanks for your response.
The capacity is much more l
Seems to be only using like 360 meg out of 7 gig free (odd
thing is I did see some used swap 4k out of 1.9) with a bunch of users (this
may be normal, but it is not going overly fast so thought I would ask).
Items I modified per commandprompt.coma nd watching this
list etc.
shared_buff
On Mon, May 09, 2005 at 09:22:40PM +0200, [EMAIL PROTECTED] wrote:
> How can i know a capacity of a pg database ?
> How many records my table can have ?
> I saw in a message that someone have 50 000 records it's possible in a table ?
> (My table have 8 string field (length 32 car)).
> Thanks for yo
The DP+DC isn't available yet, from Sun. Only QP+DC is, for which the
bid opens at 38k, that is a bit pricey -:)
-Original Message-
From: William Yu [mailto:[EMAIL PROTECTED]
Sent: Monday, May 09, 2005 1:24 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Whence the Opteron
John A Meinel wrote:
Geoffrey wrote:
Mischa Sandberg wrote:
After reading the comparisons between Opteron and Xeon processors for
Linux,
I'd like to add an Opteron box to our stable of Dells and Sparcs, for
comparison.
IBM, Sun and HP have their fairly pricey Opteron systems.
The IT people are not
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 09, 2005 2:23 PM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] PGSQL Capacity
>
> How can i know a capacity of a pg database ?
> How many records my table can have ?
> I saw in a mess
[EMAIL PROTECTED] wrote:
Hello
How can i know a capacity of a pg database ?
How many records my table can have ?
I saw in a message that someone have 50 000 records it's possible in a table ?
(My table have 8 string field (length 32 car)).
Thanks for your response.
Nanou
The capacity for a PG datab
Hello
How can i know a capacity of a pg database ?
How many records my table can have ?
I saw in a message that someone have 50 000 records it's possible in a table ?
(My table have 8 string field (length 32 car)).
Thanks for your response.
Nanou
---(end of broadcast)-
Thanks for the response :)
You could probably get your larger server to try the no-sort plan if
you said "set enable_sort = 0" first. It would be interesting to
compare the EXPLAIN ANALYZE results for that case with the other
server.
Odd, I went to investigate this switch on the larger server,
Quoting Russell Smith <[EMAIL PROTECTED]>:
> On Mon, 9 May 2005 11:49 am, Dan Harris wrote:
> > On May 8, 2005, at 6:51 PM, Russell Smith wrote:
> [snip]
> > select distinct em.incidentid, ea.recordtext as retdata, eg.long, eg.lat
> > FROM em
> > JOIN ea ON em.incidentid = ea.incidentid --- sligh
Unfortunately, Anandtech only used Postgres just a single time in his
benchmarks. And what it did show back then was a huge performance
advantage for the Opteron architecture over Xeon in this case. Where the
fastest Opterons were just 15% faster in MySQL/MSSQL/DB2 than the
fastest Xeons, it wa
On Mon, 9 May 2005, John A Meinel wrote:
Well, I'm speaking more from what I remember reading, than personal
testing. Probably 50% is too high, but I thought I remembered it being
more general than just specific cases.
Anadtech had a benchmark here:
http://www.anandtech.com/linux/showdoc.aspx?i=216
On Tue, May 10, 2005 at 02:38:41AM +1000, Neil Conway wrote:
> Jim C. Nasby wrote:
> >Having indexes that people shouldn't be using does add confusion for
> >users, and presents the opportunity for foot-shooting.
>
> Emitting a warning/notice on hash-index creation is something I've
> suggested i
Jim C. Nasby wrote:
Having indexes that people shouldn't be using does add confusion for
users, and presents the opportunity for foot-shooting.
Emitting a warning/notice on hash-index creation is something I've
suggested in the past -- that would be fine with me.
Even if there is some kind of adv
On Tue, May 10, 2005 at 01:34:57AM +1000, Neil Conway wrote:
> Christopher Petrilli wrote:
> >This being the case, is there ever ANY reason for someone to use it?
>
> Well, someone might fix it up at some point in the future. I don't think
> there's anything fundamentally wrong with hash indexes,
Anjan Dave wrote:
Wasn't the context switching issue occurring in specific cases only?
I haven't seen any benchmarks for a 50% performance difference. Neither
have I seen any benchmarks of pure disk IO performance of specific
models of Dell vs HP or Sun Opterons.
Thanks,
Anjan
Well, I'm speaking mo
Christopher Petrilli wrote:
This being the case, is there ever ANY reason for someone to use it?
Well, someone might fix it up at some point in the future. I don't think
there's anything fundamentally wrong with hash indexes, it is just that
the current implementation is a bit lacking.
If not, t
Wasn't the context switching issue occurring in specific cases only?
I haven't seen any benchmarks for a 50% performance difference. Neither
have I seen any benchmarks of pure disk IO performance of specific
models of Dell vs HP or Sun Opterons.
Thanks,
Anjan
-Original Message-
From: Joh
On 5/9/05, Neil Conway <[EMAIL PROTECTED]> wrote:
> I don't think we've found a case in which the hash index code
> outperforms B+-tree indexes, even for "=". The hash index code also has
> a number of additional issues: for example, it isn't WAL safe, it has
> relatively poor concurrency, and crea
Anjan Dave wrote:
You also want to consider any whitebox opteron system being on the
compatibility list of your storage vendor, as well as RedHat, etc. With
EMC you can file an RPQ via your sales contacts to get it approved,
though not sure how lengthy/painful that process might be, or if it's
gonn
Geoffrey wrote:
Mischa Sandberg wrote:
After reading the comparisons between Opteron and Xeon processors for
Linux,
I'd like to add an Opteron box to our stable of Dells and Sparcs, for
comparison.
IBM, Sun and HP have their fairly pricey Opteron systems.
The IT people are not swell about unsupport
You also want to consider any whitebox opteron system being on the
compatibility list of your storage vendor, as well as RedHat, etc. With
EMC you can file an RPQ via your sales contacts to get it approved,
though not sure how lengthy/painful that process might be, or if it's
gonna be worth it.
Re
Ying Lu wrote:
May I know for simple "=" operation query, for "Hash index" vs. "B-tree"
index, which can provide better performance please?
I don't think we've found a case in which the hash index code
outperforms B+-tree indexes, even for "=". The hash index code also has
a number of additional
Greetings,
We are working on speeding up the queries by creating indexes. We have
queries with searching criteria such as "select ... where *col1='...'*".
This is a simple query with only "=" operation. As a result I setup hash
index on column "col1". While, in postgreSQL 8 doc, it is wirttern:
In article <[EMAIL PROTECTED]>,
Dan Harris <[EMAIL PROTECTED]> writes:
> On May 8, 2005, at 8:06 PM, Josh Berkus wrote:
>>
>>> If I were to use tsearch2 for full-text indexing, would I need to
>>> create another table that merges all of my recordtext rows into a
>>> single 'text' field type?
>>
34 matches
Mail list logo
