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, 20
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 supp
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 Vili
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 E
and 8 Xeon cores. I usually burn up CPU more than I burn up
disks or RAM as compared to using magnetic where I had horrible IO wait
percentages, so it seems to be performing quite well so far.
Matthew Hall
> On Apr 9, 2018, at 7:36 PM, Craig James wrote:
>
> One of our four "b
> On Dec 5, 2017, at 11:23 PM, Sergei Kornilov wrote:
> You has very slow (or busy) disks, not postgresql issue. Reading 6760 * 8KB
> in 70 seconds is very bad result.
>
> For better performance you need better disks, at least raid10 (not raid5).
> Much more memory in shared_buffers can help w
On Nov 21, 2017, at 12:05 AM, Matthew Hall wrote:
>> Do you really need the artificial primary key, when you already have another
>> column that would be used as the primary key? If you need to use this it a
>> foreign key in another type, then very well might. But maintain
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 I have no idea how that really
> On Nov 21, 2017, at 10:18 PM, Henrik Cednert (Filmlance)
> wrote:
>
> WHat's the normal way to deal with compression? Dump uncompressed and use
> something that threads better to compress the dump?
I would say most likely your zlib is screwed up somehow, like maybe it didn't
get optimized
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 considerably, as the do
keyword%'::text)
Planning time: 0.252 ms
Execution time: 58442.413 ms
(8 rows)
Thanks for reading this and letting me know any recommendations.
Sincerely,
Matthew Hall
11 matches
Mail list logo
