Tom Lane wrote: > I wrote: > > I think it would be a good idea to extend the brinopers table to include > > the number of expected matches, and to complain if that's not what we got, > > rather than simply checking for zero. > > Also, further experimentation shows that there are about 30 entries in the > brinopers table that give rise to seqscan plans even when we're commanding > a bitmap scan, presumably because those operators aren't brin-indexable. > They're not the problematic cases, but things like > > ((charcol)::text > 'A'::text) > > Is there a reason to have such things in the table, or is this just a > thinko? Or is it actually a bug that we're getting such plans?
No, I left those there knowing that there are no plans involving brin -- in a way, they provide some future proofing if some of those operators are made indexable later. I couldn't think of a way to test that the plans are actually using the brin index or not, but if we can do that in some way, that would be good. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
