2011/12/30 Matteo Sgalaberni :
> 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,
> sms_messaggio_dlr
On Tue, Dec 27, 2011 at 12:29 PM, Jim Crate 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
> index? I
On 2012-01-10 18:04, Tom Lane wrote:
darklow 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 a
On Wed, Dec 7, 2011 at 6:53 PM, Tory M Blue 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" --old-bindir
Mike Blackwell 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, especially given most of the
darklow 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
seqscan the table an
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
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 o
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 o
