Title: Message
One
option that does not take advantage of any fancy indexing methods is to create a
trigger on the table, on insert/update/delete, which extracts each individual
word from the field you care about, and creates an entry in another 'keyword'
table, id = 'word', value = pk of yo
Frank van Vugt <[EMAIL PROTECTED]> writes:
> If I ditch the group by, then this contraint does get pushed into the
> subselect :
You're misinterpreting it. Without the group by, the plan is a
candidate for nestloop-with-inner-index-scan; with the group by,
there's another step in the way.
Pushi
ken <[EMAIL PROTECTED]> writes:
> Is there something wrong with rtree indexes on box data types?
Not per se, but the selectivity estimator for && is just a stub :-(.
Feel free to take a stab at improving this, or take a look at PostGIS
--- I think those guys are working the same problem even now.
> Obviously this is on toy tables
The query is simplified, yes. But the data in the tables is real, albeit
they're not that large.
> You're misinterpreting it.
I might very well be ;)
But I also get the feeling I didn't explain to you well enough what I meant...
> Without the group by, the pla
Frank van Vugt <[EMAIL PROTECTED]> writes:
> When the 'article.id < 50' constraint is added, it follows that
> 'foo.article_id < 50' is a constraint as well. Why is this constraint not
> used to avoid the seqscan on package?
We don't attempt to make every possible inference (and I don't think
yo
