On 14 July 2010 17:16, Kevin Grittner wrote:
> Ivan Voras wrote:
>
>> which didn't help.
>
> Didn't help what? You're processing each row in 22.8 microseconds.
> What kind of performance were you expecting?
Well, I guess you're right. What I was expecting is a large bump in
speed going from LIK
Ivan Voras wrote:
> which didn't help.
Didn't help what? You're processing each row in 22.8 microseconds.
What kind of performance were you expecting?
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.pos
Ivan,
here is explain analyze output - 7122 out of 528155 docs
tseval=# select count(*) from document;
count
528155
(1 row)
Time: 345,562 ms
tseval=# explain analyze select docno, title from document where vector @@
to_tsquery('english','mars');
Bitmap Heap Scan on document (cos
On 07/14/10 16:03, Kevin Grittner wrote:
> Ivan Voras < ivo...@freebsd.org > wrote:
>> On 07/14/10 15:49, Stephen Frost wrote:
>
>>> Regarding the statistics, it's entirely possible that the index
>>> is *not* the fastest way to pull this data (it's nearly 10% of
>>> the table..)
>>
>> I think
Ivan Voras < ivo...@freebsd.org > wrote:
> On 07/14/10 15:49, Stephen Frost wrote:
>> Regarding the statistics, it's entirely possible that the index
>> is *not* the fastest way to pull this data (it's nearly 10% of
>> the table..)
>
> I think that what I'm asking here is: is it reasonable for
On 07/14/10 15:49, Stephen Frost wrote:
> * Ivan Voras (ivo...@freebsd.org) wrote:
>> Total runtime: 0.507 ms
> [...]
>> Total runtime: 118.689 ms
>>
>> See in the first query where I have a simple LIMIT, it fetches random 10
>> rows quickly, but in the second one, as soon as I give it to execute
* Ivan Voras (ivo...@freebsd.org) wrote:
> Total runtime: 0.507 ms
[...]
> Total runtime: 118.689 ms
>
> See in the first query where I have a simple LIMIT, it fetches random 10
> rows quickly, but in the second one, as soon as I give it to execute and
> calculate the entire result set before I
On 07/14/10 15:25, Oleg Bartunov wrote:
> On Wed, 14 Jul 2010, Ivan Voras wrote:
>
>>> Returning 8449 rows could be quite long.
>>
>> You are right, I didn't test this. Issuing a query which returns a
>> smaller result set is much faster.
>>
>> But, offtopic, why would returning 8500 records, each
On Wed, 14 Jul 2010, Ivan Voras wrote:
Returning 8449 rows could be quite long.
You are right, I didn't test this. Issuing a query which returns a
smaller result set is much faster.
But, offtopic, why would returning 8500 records, each around 100 bytes
long so around 8.5 MB, over local unix s
On 07/14/10 14:31, Oleg Bartunov wrote:
> Something is not good with statistics, 91 est. vs 8449 actually returned.
I don't think the statistics difference is significant - it's actually
using the index so it's ok. And I've run vacuum analyze just before
starting the query.
> Returning 8449 rows
Something is not good with statistics, 91 est. vs 8449 actually returned.
Returning 8449 rows could be quite long.
Oleg
On Wed, 14 Jul 2010, Ivan Voras wrote:
Here's a query and its EXPLAIN ANALYZE output:
cms=> select count(*) from forum;
count
---
90675
(1 row)
cms=> explain analyze se
Here's a query and its EXPLAIN ANALYZE output:
cms=> select count(*) from forum;
count
---
90675
(1 row)
cms=> explain analyze select id,title from forum where _fts_ @@
'fer'::tsquery;
QUERY PLAN
12 matches
Mail list logo
