| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nicolas Seinlet <nicolas(at)seinlet(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_trgm upgrade to 1.6 led to load average increase |
| Date: | 2026-01-21 16:27:56 |
| Message-ID: | 2215067.1769012876@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Nicolas Seinlet <nicolas(at)seinlet(dot)com> writes:
> We issue queries like :
> SELECT model, res_id FROM ir_model_data WHERE module='base' AND name='public_user';
> With 1.0 extension, the query is planned with a matching btree index:
> "ir_model_data_module_name_uniq_index" UNIQUE, btree (module, name)
> With 1.6 extension, the query is planned with a gist index:
> "ir_model_data_name_idx2" gist (name gist_trgm_ops)
> 1.0 extension executes the query in 0.1ms, while 1.6 in 100ms
It seems quite odd that the planner would prefer an index
using only one of the two clauses. It must be concluding that
the gist indexscan will be cheaper, but it's hard to see why
that would be.
Could we see EXPLAIN ANALYZE output for those two cases?
Are the statistics for the table up-to-date?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2026-01-21 16:59:17 | Re: pgBadger and postgres_fdw |
| Previous Message | Colin 't Hart | 2026-01-21 16:12:44 | Re: pgBadger and postgres_fdw |