Re: [PERFORM] slow query

Scott Marlowe wrote: > > OK, I've got a query that's running slow the first time, then fast. > But I can't see where the time is really being spend on the first run. > Query and plan attached to preserve formatting. Often this is from caching -- the first time the system has to go to disk to ge

Re: [PERFORM] Slow table update

Laszlo Nagy wrote: > >> My other idea was that there are so many indexes on this table, maybe > >> the update is slow because of the indexes? > >> > > > > Updating indexes is certainly very far from being free. How many is > > "many"? > > > Number of indexes = 15. > > 3 indexex are on "

Re: [PERFORM] Slow table update

Laszlo Nagy wrote: > > Laszlo Nagy wrote: > > SQL: > > > > update product set sz_category_id=null where am_style_kw1 is not null > > and sz_category_id is not null > Hmm, this query: > > ?select count(*) from product where am_style_kw1 is not null and > sz_category_id is not null and sz_catego

Re: [PERFORM] Experience with HP Smart Array P400 and SATA drives?

Me, I'd *never) allow RAID-5 for data I cared abut. Among other references, see (sorry for top-posting -- challenged reader and no other content to add) Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message,

Re: [PERFORM] select on 22 GB table causes "An I/O error occured while sending to the backend." exception

Bill Moran wrote: > In response to Greg Smith <[EMAIL PROTECTED]>: > >> > > I don't know, Greg. First off, the solution of making the postmaster > immune to the OOM killer seems better than disabling overcommit to me > anyway; and secondly, I don't understand why we should avoid making > the P

Re: [PERFORM] Difference between 8.1 & 8.3

Patrick Vachon wrote: > Hi guys, > > I've got a query that is running slower on 8.3 than on 8.1 (with > equivalent server config), > because the join ordering is not the same, at least that's my guess... ;-) > > In 8.1.4, table A had 122880 pages, B 112690 pages and C 80600 pages. > Now in 8.3.

Re: [PERFORM] need to speed up query

Justin -- You wrote: > > i've had to write queries to get trail balance values out of the GL > transaction table and i'm not happy with its performance > > > The table has 76K rows growing about 1000 rows per working day so the > performance is not that great it takes about 20 to 30 seconds

Re: [PERFORM] t1.col like '%t2.col%'

Joshua Drake spake thusly: > On Fri, 29 Feb 2008 15:52:31 -0800 > "Dan Kaplan" <[EMAIL PROTECTED]> wrote: > > > I learned a little about pg_trgm here: > > http://www.sai.msu.su/~megera/postgres/gist/pg_trgm/README.pg_trgm > > > > But this seems like it's for finding similarities, not substrings.

Re: R: [PERFORM] R: DELETE queries slow down

"Galantucci Giovanni" <[EMAIL PROTECTED]> wrote: > > No, I perform a single DELETE for about 8/10 rows at a time. > > Yesterday I tried to raise the parameter default_statistics_target on the > file postgresql.conf, setting it to 50 (previously it was set to 10) and > everything went ok

FW: [PERFORM] optimize query with a maximum(date) extraction

bad address kep his from going to the list on my first try ... apologies to the moderators. -Original Message- From: Gregory Williamson Sent: Wed 9/5/2007 4:59 AM To: JS Ubei; pgsql-performance@postgresql.org Subject: RE: [PERFORM] optimize query with a maximum(date) extraction In