Re: [PERFORM] [GENERAL] Text Search vs MYSQL vs Lucene

2004-09-09 Thread Shridhar Daithankar
On Thursday 09 Sep 2004 6:26 pm, Vic Cekvenich wrote: > What would be performance of pgSQL text search vs MySQL vs Lucene (flat > file) for a 2 terabyte db? Well, it depends upon lot of factors. There are few questions to be asked here.. - What is your hardware and OS configuration? - What type o

Re: [PERFORM] TSearch2 and optimisation ...

2004-09-09 Thread Hervé Piedvache
George, Le Jeudi 26 Août 2004 19:58, George Essig a écrit : > Bill Footcow wrote: > > ... > > > I have done a simple request, looking for title or description having > > Postgres inside order by rank and date, like this : > > SELECT a.title, a.id, a.url, to_char(a.r_date, 'DD/MM/ HH24:MI:SS')

Re: [PERFORM] fsync vs open_sync

2004-09-09 Thread Mark Wong
On Sun, Sep 05, 2004 at 12:16:42AM -0500, Steve Bergman wrote: > On Sat, 2004-09-04 at 23:47 -0400, Christopher Browne wrote: > > The world rejoiced as [EMAIL PROTECTED] ("Merlin Moncure") wrote: > > > Ok, you were right. I made some tests and NTFS is just not very > > > good in the general case.

[PERFORM] Costly "Sort Key" on indexed timestamp column

2004-09-09 Thread ogjunk-pgjedan
Hello, I'm tuning my PostgreSQL DB (7.3.4) and have come across a query that doesn't use an index I created specially for it, and consequently takes circa 2 seconds to run. :( The ugly query looks like this (the important part is really at the very end - order by piece): select userinfo1_.id as

Re: [PERFORM] Multiple Uniques

2004-09-09 Thread Neil Conway
Tom Lane wrote: Markus Schaber <[EMAIL PROTECTED]> writes: So, now my question is, why does the query optimizer not recognize that it can throw away those "non-unique" Sort/Unique passes? Because the issue doesn't come up often enough to justify expending cycles to check for it. How many cycles are

Re: [PERFORM] Multiple Uniques

2004-09-09 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Because the issue doesn't come up often enough to justify expending >> cycles to check for it. > How many cycles are we really talking about, though? I have a patch > which I'll send along in a few days which implements a similar > opt

Re: [PERFORM] Costly "Sort Key" on indexed timestamp column

2004-09-09 Thread Tom Lane
<[EMAIL PROTECTED]> writes: > I'm tuning my PostgreSQL DB (7.3.4) and have come across a query that > doesn't use an index I created specially for it, and consequently takes > circa 2 seconds to run. :( > ... > The output of EXPLAIN ANALYZE follows. Note how 99% of the total cost > comes from "Sor

Re: [PERFORM] Multiple Uniques

2004-09-09 Thread Greg Stark
Tom Lane <[EMAIL PROTECTED]> writes: > Neil Conway <[EMAIL PROTECTED]> writes: > > > How many cycles are we really talking about, though? I have a patch > > which I'll send along in a few days which implements a similar > > optimization: if a subselect is referenced by EXISTS or IN, we can >