For indexes the SSDs are at least 4X faster but you won't get that to happen
unless you fix the planner tunable for the random page fetch cost first. Super
important change for SSDs.
Matthew Hall
> On Oct 8, 2019, at 5:12 PM, Rick Otten wrote:
>
>
>> On Tue, Oct 8, 2019 at
On Jul 26, 2018, at 9:44 AM, Tom Lane wrote:
>
> Nicolas Even writes:
>> However when I run the same (as far as I understand it) query but with
>> the ALL operator, the index is not used:
>> explain analyze select name from totoz where name ilike all(array['%tot%']);
>
> There's only index
Is there a reason you used GIST on your pg_trgm indices and not GIN? In my
tests and previous posts on here, it nearly always performs worse. Also, did
you make sure if it's really SSD and set the random_page_cost accordingly?
Matthew Hall
> On Jun 20, 2018, at 8:21 AM, Sasa Vilic wr
s actually stored inside
of those that will help.
Matthew Hall
> On Jun 5, 2018, at 7:17 AM, Fred Habash wrote:
>
> Trying to optimize the Elapsed Time (ET) of this query. Currently, it is
> hovering around 3 hrs.
>
> Running a 'vaccum analyse' had no effect on ET. Even fo
On Nov 22, 2017, at 5:06 AM, Henrik Cednert (Filmlance)
wrote:
>
> When investigating the zlib lead I looked at 8.4 installation and 9.5
> installation. 9.5 includes zlib.h (/Library/PostgreSQL//9.5/include/zlib.h),
> but 8.4 doesn't. But that's a header file and
Hi Jeff,
Thanks so much for writing. You've got some great points.
> On Nov 20, 2017, at 5:42 PM, Jeff Janes wrote:
> While I have not done exhaustive testing, from the tests I have done I've
> never found gist to be better than gin with trgm indexes.
Thanks, this helps
ading this and letting me know any recommendations.
Sincerely,
Matthew Hall