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
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,
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
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
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
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
[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: