Jeremiah Jahn wrote:
I have about 5M names stored on my DB. Currently the searches are very
quick unless, they are on a very common last name ie. SMITH. The Index
is always used, but I still hit 10-20 seconds on a SMITH or Jones
search, and I average about 6 searches a second and max out at about
I'm not sure what the answer is but maybe I can help? Would clustering the
name index make this faster? I thought that would bunch up the pages so the
names were more or less in order, which would improve search time. Just a
guess though.
Ken
- Original Message -
From: Jeremiah Jahn
yes, it does. I forgot to mention, that I also have clustering on that
table by my name_field index. My Bad.
On Thu, 2005-03-03 at 12:00 -0500, Ken Egervari wrote:
I'm not sure what the answer is but maybe I can help? Would clustering the
name index make this faster? I thought that would
Jeremiah Jahn wrote:
I have about 5M names stored on my DB. Currently the searches are very
quick unless, they are on a very common last name ie. SMITH. The Index
is always used, but I still hit 10-20 seconds on a SMITH or Jones
search, and I average about 6 searches a second and max out at about
Jeremiah,
I have about 5M names stored on my DB. Currently the searches are very
quick unless, they are on a very common last name ie. SMITH. The Index
is always used, but I still hit 10-20 seconds on a SMITH or Jones
search, and I average about 6 searches a second and max out at about
30/s.
Hi, Jeremiah,
Jeremiah Jahn schrieb:
yes, it does. I forgot to mention, that I also have clustering on that
table by my name_field index. My Bad.
Fine. Did you run ANALYZE and CLUSTER on the table after every large
bunch of insertions / updates?
Markus
--
Markus Schaber | Dipl.
On Thu, 2005-03-03 at 11:46 -0600, John A Meinel wrote:
Jeremiah Jahn wrote:
I have about 5M names stored on my DB. Currently the searches are very
quick unless, they are on a very common last name ie. SMITH. The Index
is always used, but I still hit 10-20 seconds on a SMITH or Jones
On Thu, 2005-03-03 at 09:44 -0800, Josh Berkus wrote:
Jeremiah,
I have about 5M names stored on my DB. Currently the searches are very
quick unless, they are on a very common last name ie. SMITH. The Index
is always used, but I still hit 10-20 seconds on a SMITH or Jones
search, and I
-Original Message-
From: Jeremiah Jahn [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 2:15 PM
To: John A Meinel
Cc: postgres performance
Subject: Re: [PERFORM] name search query speed
[...]
So the count for this is generated on the fly needed for
pagination in the app
query.
On Thu, 2005-03-03 at 14:26 -0600, Dave Held wrote:
-Original Message-
From: Jeremiah Jahn [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 2:15 PM
To: John A Meinel
Cc: postgres performance
Subject: Re: [PERFORM] name search query speed
[...]
So the count
Jeremiah Jahn wrote:
On Thu, 2005-03-03 at 11:46 -0600, John A Meinel wrote:
...
Not really, about 2% of the returned rows are thrown away for security
reasons based on the current user, security groups they belong to and
different flags in the data itself. So the count for this is generated
on
Hi, Jeremiah,
Jeremiah Jahn schrieb:
doesn't that cause two queries? I used to do it that way and cut my time
substantially by counting in-line. Even though the results were cached
it still took more time.
This sounds rather strange.
Also since the tables is constantly be updated
the
Jeremiah Jahn wrote:
I have about 5M names stored on my DB. Currently the searches are very
quick unless, they are on a very common last name ie. SMITH. The Index
is always used, but I still hit 10-20 seconds on a SMITH or Jones
search, and I average about 6 searches a second and max out at about
13 matches
Mail list logo
