It appears that the ORDER BY rank operation is the slowing factor.
If I remove it then the query is pretty fast. Is there another way
to perform ORDER BY such that it does not do a sort?
Benjamin
On Oct 5, 2007, at 3:57 PM, Benjamin Arai wrote:
On Oct 5, 2007, at 8:32 AM, Oleg Bartunov
Oh, I see. I didn't look carefully at the EXPLAIN ANALYZE I posted.
So, is there a solution to the rank problem?
Benjamin
On Oct 11, 2007, at 8:53 AM, Tom Lane wrote:
Benjamin Arai [EMAIL PROTECTED] writes:
It appears that the ORDER BY rank operation is the slowing factor.
If I remove
Hi,
I have very slow performance for a TSearch2 table. I have pasted the
EXPLAIN ANALYZE queries below. 12 seconds is slow for almost any
purpose. Is there any way to speed this up?
# explain analyze select * FROM fulltext_article, to_tsquery
('simple','dog') AS q WHERE idxfti @@ q
On Oct 5, 2007, at 8:32 AM, Oleg Bartunov wrote:
On Fri, 5 Oct 2007, Tom Lane wrote:
Benjamin Arai [EMAIL PROTECTED] writes:
# explain analyze select * FROM fulltext_article, to_tsquery
('simple','dog') AS q WHERE idxfti @@ q ORDER BY rank(idxfti, q)
DESC;
QUERY PLAN
PGP SIGNED MESSAGE-
Hash: SHA1
Benjamin Arai wrote:
This kind of disappointing, I was hoping there was more that could
be done.
There has to be another way to do incremental indexing without
loosing
that much performance.
What makes you think you are loosing performance by using
MESSAGE-
Hash: SHA1
Benjamin Arai wrote:
As stated in the previous email if I use partitioning then queries
will
be executed sequentially - i.e., instead of log(n) it would be (#
partitions) * log(n). Right?
The planner will consider every relevant partition during the
execution.
Which may
Hi,
I have an application which loads millions of NEW documents each month
into a PostgreSQL tsearch2 table. I have the initial version completed
and searching performance is great but my problem is that each time a
new
month rolls around I have to drop all the indexes do a COPY and re-index
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This kind of disappointing, I was hoping there was more that could be
done.
There has to be another way to do incremental indexing without
loosing that much performance.
Benjamin
On Aug 24, 2007, at 6:29 PM, Joshua D. Drake wrote:
Hi,
If I have a query such as:
SELECT * FROM (SELECT * FROM A) UNION ALL (SELECT * FROM B) WHERE
blah='food';
Assuming the table A and B both have the same attributes and the data
between the table is not partitioned in any special way, does Postgresql
execute WHERE blah=food on both table
Thanks! This exactly what I was looking for.
Benjamin Arai
[EMAIL PROTECTED]
http://www.benjaminarai.com
-Original Message-
From: Bruno Wolff III [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 11:56 AM
To: Benjamin Arai
Cc: pgsql-performance@postgresql.org
Subject: Re: Question
Hi,
Will simple queries
such as "SELECT * FROM blah_table WHERE tag='x'; work any faster by putting them
into a stored procedure?
Benjamin Arai
[EMAIL PROTECTED]
http://www.benjaminarai.com
would be a ball park figure?
Benjamin Arai
[EMAIL PROTECTED]
http://www.benjaminarai.com
My original plan was to buy a 3WARE card and put a 1GB of
memory on it to improve writes but I am not sure if that is actually going to
help the issue if fsync=off.
Benjamin Arai
[EMAIL PROTECTED]
http://www.benjaminarai.com
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED
I have been working
on optimizing a PostgreSQL server for weekly updates where data is only updated
once a week then for the remaining portion of the week the data is static.
So far I have set fsync to off and increased the segment size among other
things. I need to ensure that at the end
r a factor of 10. The
downside is that SW RAID is a pain in the neck for management - you have
to shut down the Linux host when a disk fails to replace it.
- Luke
---(end of broadcast)---
TIP 6: explain analyze is your friend
--
Benjamin A
, but frankly I prefer HW RAID if it performs well. So far the SATA host-based RAID is blowing the doors off of every other HW RAID solution I've tested.
- Luke
--
Benjamin Arai
[EMAIL PROTECTED]
http://www.benjaminarai.com
16 matches
Mail list logo
