On Mon, 2018-12-03 at 18:41 +, Scott Rankin wrote:
> Upon further analysis, this is - unsurprisingly - taking place when we have
> multiple prefixed search terms in a ts_query going against a tsvector index.
>
> We have roughly 30 million rows in the table, and the search column is
> basical
Upon further analysis, this is - unsurprisingly - taking place when we have
multiple prefixed search terms in a ts_query going against a tsvector index.
We have roughly 30 million rows in the table, and the search column is
basically a concatenation of a location's name (think "Walmart #123456")
On 11/28/18, 2:18 PM, "Justin Pryzby" wrote:
On Wed, Nov 28, 2018 at 07:08:53PM +, Scott Rankin wrote:
> We recently moved our production database systems from a 9.4 running on a
self-managed EC2 instance to 9.6.10 on Amazon’s AWS (same RAM, CPU). After the
move, we’re finding tha
On Wed, Nov 28, 2018 at 07:08:53PM +, Scott Rankin wrote:
> We recently moved our production database systems from a 9.4 running on a
> self-managed EC2 instance to 9.6.10 on Amazon’s AWS (same RAM, CPU). After
> the move, we’re finding that certain queries that we run against a GIN
> full-
Hello all,
We recently moved our production database systems from a 9.4 running on a
self-managed EC2 instance to 9.6.10 on Amazon’s AWS (same RAM, CPU). After the
move, we’re finding that certain queries that we run against a GIN full-text
index have some occasionally very slow executions and
