Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-07 Thread Andrus
Thank you. I ran manually analyze command. After that query runs fast. I have enabled autovacuum and statitics collection in config file. Every day a lot of rows are added to dok table. However it seems that statitics is not collected (autovacuum is not running) Any idea autovacuum is not running

Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-06 Thread Martijn van Oosterhout
On Wed, Dec 05, 2007 at 11:32:59AM +0200, Andrus wrote: > I do'nt have this index. > dok.kuupaev||dok.kellaaeg conditon should applied after index search is > performed. > It filters out only a small number of rows additionally to the plain kuupaev > filter. > So adding index on dok.kuupaev||dok.

Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-06 Thread Andrus
Thank you very much for quick reply. > can you please give us the types of dok.kuupaev and dok.kellaaeg? I > think a simple fix is possible here. dok.kuupaev type is DATE dok.kellaaeg type is character(5) NOT NULL DEFAULT '' and is used to represent dokument time in format hh mm Databas

Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-06 Thread Andrus
> I'm not sure what that comment is supposed to mean. > > PG is using the index for the condition > dok.kuupaev BETWEEN '2007-11-01' AND '2007-12-04' > > but there is no index that matches the expression > dok.kuupaev||dok.kellaaeg BETWEEN '2007-11-01' AND '2007-12-0423 59' > > If you look at your

Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-06 Thread Andrus
> just small correction here...expressions like that in the create index > need an extra set of parens (but I agree with your sentiment): > CREATE INDEX dokindex ON dok ((kuupaeve||kellaaeg)) I tried CREATE INDEX dok_kuupaev_kellaaeg_idx ON dok ((kuupaev||kellaaeg)); but got error ERROR: functi

Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-05 Thread Bill Moran
In response to "Andrus" <[EMAIL PROTECTED]>: > Thank you very much for quick reply. Keep the mailing list included in this discussion. > > can you please give us the types of dok.kuupaev and dok.kellaaeg? I > > think a simple fix is possible here. > > dok.kuupaev type is DATE > > dok.kellaae

Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-04 Thread Merlin Moncure
On Dec 4, 2007 8:02 PM, Bill Moran <[EMAIL PROTECTED]> wrote: > "Andrus" <[EMAIL PROTECTED]> wrote: > > Using string concatenation in where clause causes huge perfomance loss: > > > > explain analyze select > >rid.toode > >FROM dok JOIN rid USING (dokumnr) > >JOIN toode USING (toode

Re: [GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-04 Thread Bill Moran
"Andrus" <[EMAIL PROTECTED]> wrote: > > Using string concatenation in where clause causes huge perfomance loss: > > explain analyze select >rid.toode >FROM dok JOIN rid USING (dokumnr) >JOIN toode USING (toode) >LEFT JOIN artliik using(grupp,liik) >WHERE rid.toode='NAH S' >

[GENERAL] Avoid huge perfomance loss on string concatenation

2007-12-04 Thread Andrus
Using string concatenation in where clause causes huge perfomance loss: explain analyze select rid.toode FROM dok JOIN rid USING (dokumnr) JOIN toode USING (toode) LEFT JOIN artliik using(grupp,liik) WHERE rid.toode='NAH S' AND dok.kuupaev BETWEEN '2007-11-01' AND '2007-12-04' a