You are running afoul of the Linux OOM killer which is what the kernel uses
when it experiences memory pressure.
You could exclude PostgreSQL from the OOM killer, you'll need to look up on how
to do that for your particular Linux distro.
We've experienced this with queries that consume more RAM
am missing that affects materialized view refreshes?
3. Should I just go with a table that is dropped and recreated instead? I
was hoping to avoid this.
--
Sincerely,
Jeremiah Bauer
Agri Stats, Inc.
CONFIDENTIALITY NOTICE: The information contained in this email (and any
attachments
My question is: what indexes are on public.large_table? Hopefully there's a
compound b-tree index on id1, id2, id3.
There is not, after further investigation. There are these 4 indexes that
involve id1, id2, and id3. Should I try creating an index on all three of the
columns?
CREATE INDEX IF
That'd be a band-aid at best, because we know that the query used to
define the materialized view runs in a reasonable amount of time on it's
own, as does a CTAS. So either the REFRESH is doing something odd when
writing into the new relation (which looking at the code seems very
unlikely), or REF
