On Sun, 2005-08-21 at 16:13 -0400, Ron wrote:
> At 10:54 AM 8/21/2005, Jeremiah Jahn wrote:
> >On Sat, 2005-08-20 at 21:32 -0500, John A Meinel wrote:
> > > Ron wrote:
> > >
> > > Well, since you can get a read of the RAID at 150MB/s, that means that
> &g
On Sat, 2005-08-20 at 21:32 -0500, John A Meinel wrote:
> Ron wrote:
> > At 02:53 PM 8/20/2005, Jeremiah Jahn wrote:
> >
> >> On Fri, 2005-08-19 at 16:03 -0500, John A Meinel wrote:
> >> > Jeremiah Jahn wrote:
> >> > > On
On Fri, 2005-08-19 at 16:03 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > On Fri, 2005-08-19 at 12:18 -0500, John A Meinel wrote:
> >
> >>Jeremiah Jahn wrote:
> >>
>
>
> ...
>
> >>
> >>Well, in general, 3ms for a single l
On Sat, 2005-08-20 at 11:59 -0400, Ron wrote:
> At 04:11 PM 8/19/2005, Jeremiah Jahn wrote:
> >On Fri, 2005-08-19 at 14:23 -0500, John A Meinel wrote:
> > > Ron wrote:
> > > > At 01:18 PM 8/19/2005, John A Meinel wrote:
> > > >
> > > >> J
0 : 056k| 160k
2048M| 21 4 75 0 0 0
On Fri, 2005-08-19 at 16:07 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > Rebuild in progress with just ext3 on the raid array...will see if this
> > helps the access times. If it doesn't I'll mess with the stri
a
factor, but I really don't see it causing problems on index read speed
esp. when it's not running.
thanx for your help, I really appreciate it.
-jj-
On Fri, 2005-08-19 at 14:23 -0500, John A Meinel wrote:
> Ron wrote:
> > At 01:18 PM 8/19/2005, John A Meinel wrote:
On Fri, 2005-08-19 at 14:23 -0500, John A Meinel wrote:
> Ron wrote:
> > At 01:18 PM 8/19/2005, John A Meinel wrote:
> >
> >> Jeremiah Jahn wrote:
> >> > Sorry about the formatting.
> >> >
> >> > On Thu, 2005-08-18 at 12:55 -0500,
On Fri, 2005-08-19 at 12:18 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > Sorry about the formatting.
> >
> > On Thu, 2005-08-18 at 12:55 -0500, John Arbash Meinel wrote:
> >
> >>Jeremiah Jahn wrote:
> >>
> >>
>
>
Sorry about the formatting.
On Thu, 2005-08-18 at 12:55 -0500, John Arbash Meinel wrote:
> Jeremiah Jahn wrote:
>
> >here's an example standard query. Ireally have to make the first hit go
> >faster. The table is clustered as well on full_name as well. 'Smith%'
that took a little while to get through the system didn't it. Please
ignore.
> Ingrate, n.: A man who bites the hand that feeds him, and then complains
> of indigestion.
--
A free society is one where it is safe to be unpopular.
-- Adlai Stevenson
---(en
The system is a dual Xenon with 6Gig of ram and 14 73Gig 15K u320 scsi
drives. Plus 2 raid 1 system dives.
RedHat EL ES4 is the OS.
Any1 have any suggestions as to the configuration? The database is about
60 Gig's. Should jump to 120 here quite soon. Mus of the searches
involve people's names.
7.4 is the pg version BTWgoing to switch to 8 if it's worth it.
Ingrate, n.: A man who bites the hand that feeds him, and then complains
of indigestion.
--
"Don't say yes until I finish talking."
-- Darryl F. Zanuck
signature.asc
Description: This is a digitally signed mess
n case_data (cost=0.00..5.29
rows=3 width=53) (actual time=0.017..0.020 rows=1 loops=4906)
Index Cond: (('IL081025J'::text =
(case_data.court_ori)::text) AND ((case_data.case_id)::text =
("outer".case_id)::text))
Total runtime: 694.639 ms
(18 rows)
On
On Wed, 2005-08-17 at 21:21 -0500, John A Meinel wrote:
> Jeremiah Jahn wrote:
> > I just put together a system with 6GB of ram on a 14 disk raid 10 array.
> > When I run my usual big painful queries, I get very little to know
> > memory usage. My production box (raid 5 4GB
I just put together a system with 6GB of ram on a 14 disk raid 10 array.
When I run my usual big painful queries, I get very little to know
memory usage. My production box (raid 5 4GB ram) hovers at 3.9GB used
most of the time. the new devel box sits at around 250MB.
I've switched to an 8.0 syste
7.4 is the pg version BTWgoing to switch to 8 if it's worth it.
Ingrate, n.: A man who bites the hand that feeds him, and then complains
of indigestion.
--
"Don't say yes until I finish talking."
-- Darryl F. Zanuck
--
"Don't say yes until I finish talking."
econd 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
> > Subje
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
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 sec
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" <[EMAIL PROTECTED]>
> To: "postgres performance"
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. Any suggestions
umn needs updating; I suggest:
>
> ALTER TABLE actor ALTER COLUMN full_name SET STATISTICS 100;
> ANALYZE actor;
>
> And if it's still choosing a slow nested loop, up the stats to 250.
--
Jeremiah Jahn <[EMAIL PROTECTED]>
---(end of broadc
On Wed, 2003-11-26 at 16:32, Hannu Krosing wrote:
> Jeremiah Jahn kirjutas K, 26.11.2003 kell 22:14:
> > I was wondering if there is something I can do that would act similar to
> > a index over more than one table.
> >
> > I have about 3 million people in my DB a
actor.actor_id)::text =
("outer".actor_id)::text)
-> Index Scan using event_pkey on event (cost=0.00..5.83 rows=1
width=52)
Index Cond: (("outer".event_id)::text = (event.event_id)::text)
Filter: (event_date_time &g
24 matches
Mail list logo
