Tom Lane-2 wrote > Jake Magner < > jakemagner90@ > > writes: >> I tried without doing an INSERT at all, just running the SELECT queries >> and >> the result is the same. Nested loop is chosen but is much slower. > > FWIW, I just noticed that the comparisons you're using are plain equality > of the arrays. While a GIN array index supports that, it's not exactly > its strong suit: the sort of questions that index type supports well are > more like "which arrays contain value X?". I wonder if it'd be worth > creating btree indexes on the array column. I added btree indexes and now the nested loop uses those and is a bit faster than the hash join. So the planner just misestimates the cost of doing the equality comparisons? I'd prefer not to add more indexes, the hash join performance is fast enough if it would just choose that but I'm reluctant to turn off nested loops in case the table gets a lot bigger. -- View this message in context: http://postgresql.nabble.com/Planner-chooses-slow-index-heap-scan-despite-accurate-row-estimates-tp5905357p5905453.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
