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 of

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') as dt,

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. I've seen

[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 we

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

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 Sort Key: