Some info:
PostgreSQL version: 9.1.2
Table cache:
Rows count: 3 471 081
Column tsv tsvector
Index cache_tsv USING gin (tsv)
If i do query like THIS:
*SELECT id FROM table WHERE tsv @@ to_tsquery('test:*');*
It uses index and returns results immediately:
explain analyze
'Bitmap Heap Scan on
Some info:
PostgreSQL version: 9.1.2
Table cache:
Rows count: 3 471 081
Column tsv tsvector
Index cache_tsv USING gin (tsv)
If i do query like THIS:
*SELECT id FROM table WHERE tsv @@ to_tsquery('test:*');*
It uses index and returns results immediately:
explain analyze
'Bitmap Heap Scan on
We have a set of large tables. One of the columns is a status indicator
(active / archived). The queries against these tables almost always
include the status, so partitioning against that seems to makes sense from
a logical standpoint, especially given most of the data is archived and
most of
darklow dark...@gmail.com writes:
But the performance problems starts when i do the same query specifying
LIMIT.
*SELECT id FROM cache WHERE tsv @@ to_tsquery('test:*') limit 20;*
By some reason index is not used.
It apparently thinks there are enough matches that it might as well just
Mike Blackwell mike.blackw...@rrd.com wrote:
We have a set of large tables. One of the columns is a status indicator
(active / archived). The queries against these tables almost always include
the status, so partitioning against that seems to makes sense from a logical
standpoint,
On Wed, Dec 7, 2011 at 6:53 PM, Tory M Blue tmb...@gmail.com wrote:
Well thought it was maybe just going from 8.4.4 to 9.1.1 so upgraded
to 8.4.9 and tried pg_upgrade again (this is 64bit) and it's failing
-bash-4.0$ /tmp/pg_upgrade --check --old-datadir /data/db
--new-datadir /data1/db
On 2012-01-10 18:04, Tom Lane wrote:
darklowdark...@gmail.com writes:
But the performance problems starts when i do the same query specifying
LIMIT.
*SELECT id FROM cache WHERE tsv @@ to_tsquery('test:*') limit 20;*
By some reason index is not used.
It apparently thinks there are enough
On Tue, Dec 27, 2011 at 12:29 PM, Jim Crate jim...@gmail.com wrote:
My question is why does it do a seq scan when it flattens this subquery into
a JOIN? Is it because the emsg_messages table is around 1M rows? Are there
some guidelines to when the planner will prefer not to use an available
2011/12/30 Matteo Sgalaberni sg...@sgala.com:
I'm sorry, I pasted the wrong ones, but the results are the same, here A and
B again:
Query A
# EXPLAIN ANALYZE SELECT sms.id AS id_sms
FROM
sms_messaggio AS sms,
