Re: [GENERAL] Performance problem on RH7.1

2004-06-29 Thread Együd Csaba
Hi, > Generally you want '=' conditions on the leftmost index keys; any > inequality or range constraint should be on the rightmost > keys. You can see this by thinking about the range of index entries that > the scan will have to pass over. I see. Just like in your earlier example, where you red

Re: [GENERAL] Performance problem on RH7.1

2004-06-29 Thread Együd Csaba
Hi Tom, > Good, but you're not there yet --- the Sort step shouldn't be there at > all. You've still got some inconsistency between the ORDER BY and the > index. Check my example again. yes yes I missed that, sorry. Now don't mention the performance because I couldn' see anything but the result.

Re: [GENERAL] Performance problem on RH7.1

2004-06-28 Thread Tom Lane
=?iso-8859-2?Q?Egy=FCd_Csaba?= <[EMAIL PROTECTED]> writes: > Limit (cost=30.28..30.28 rows=1 width=58) (actual time=0.19..0.19 rows=1 > loops=1) > -> Sort (cost=30.28..30.30 rows=7 width=58) (actual time=0.18..0.18 > rows=2 loops=1) > Sort Key: stockid, productid, changeid, date, "time

Re: [GENERAL] Performance problem on RH7.1

2004-06-28 Thread Együd Csaba
TECTED] > Cc: 'Alvaro Herrera'; '[EMAIL PROTECTED] (E-mail)' > Subject: Re: [GENERAL] Performance problem on RH7.1 > > > =?iso-8859-2?Q?Egy=FCd_Csaba?= <[EMAIL PROTECTED]> writes: > >> I'd also suggest dropping the EXECUTE approach, as this is &g

Re: [GENERAL] Performance problem on RH7.1

2004-06-28 Thread Tom Lane
=?iso-8859-2?Q?Egy=FCd_Csaba?= <[EMAIL PROTECTED]> writes: >> I'd also suggest dropping the EXECUTE approach, as this is costing you >> a re-plan on every call without buying much of anything. > Do you mean I should use PERFORM instead? Or what else? > Do you mean the "for R in execute" statements

Re: [GENERAL] Performance problem on RH7.1

2004-06-28 Thread Együd Csaba
> The major time sink is clearly here: > > > -> Index Scan using t_stockchanges_fullindex on > t_stockchanges > > (cost=0.00..28.74 rows=7 width=46) > > (actual time=0.14..9.03 rows=6 loops=1) > >Index Cond: ((date <= '2004.06.28'::bpchar) > AND (stockid = 1)

Re: [GENERAL] Performance problem on RH7.1

2004-06-27 Thread Tom Lane
=?iso-8859-1?Q?Egy=FCd_Csaba?= <[EMAIL PROTECTED]> writes: > It is strange that the laptop substantially faster then the server. The > get_stock* functions are executed 2-3 times faster. So what do those stored procedures do exactly? What it smells like to me is a bad plan for a query executed in

Re: [GENERAL] Performance problem on RH7.1

2004-06-27 Thread Együd Csaba
hing wrong. Thank you all. Best regards, -- Csaba Együd > -Original Message- > From: Alvaro Herrera [mailto:[EMAIL PROTECTED] > Sent: 2004. június 27. 3:38 > To: Együd Csaba > Cc: [EMAIL PROTECTED] (E-mail) > Subject: Re: [GENERAL] Performance problem on RH7.1 > > &g

Re: [GENERAL] Performance problem on RH7.1

2004-06-26 Thread Alvaro Herrera
On Sat, Jun 26, 2004 at 12:16:17PM +0200, Együd Csaba wrote: > I've a problem with the perfprmance of the production environment. > I've two db servers. One on my laptop computer (2Ghz, 1GB, WinXP, Cygwin, > Postgres 7.3.4) and one on a production server (2GHz, 1GB, Ultra SCSI, > RH7.1, Postgres 7

Re: [GENERAL] Performance problem on RH7.1

2004-06-26 Thread Scott Marlowe
On Sat, 2004-06-26 at 04:16, EgyÃd Csaba wrote: > Hi All, > I've a problem with the perfprmance of the production environment. > I've two db servers. One on my laptop computer (2Ghz, 1GB, WinXP, Cygwin, > Postgres 7.3.4) and one on a production server (2GHz, 1GB, Ultra SCSI, > RH7.1, Postgres 7.3.2