Search Postgresql Archives

Re: Bad planning data resulting in OOM killing of postgres

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 13, 2017 at 12:43 PM, David Hinkle <hinkle@xxxxxxxxxxxxxx> wrote:
Thanks Jeff,

No triggers or foreign key constrains:

psql:postgres@cipafilter = \d+ titles
                                                     Table "public.titles"
 Column  │       Type        │                        Modifiers
                 │ Storage  │ Stats target │ Description
─────────┼───────────────────┼──────────────────────────────────────────────────────────┼──────────┼──────────────┼─────────────
 title   │ character varying │
                 │ extended │              │
 titleid │ integer           │ not null default
nextval('titles_titleid_seq'::regclass) │ plain    │              │
Indexes:
    "titles_pkey" PRIMARY KEY, btree (titleid)
    "titles_md5_title_idx" btree (md5(title::text))

Do you see anything in there that would be problematic?


I'm out of ideas here.  What happens if you just select the rows, rather than deleting them?  Does it have memory problems then?  If not, can you post the explain (analyze, buffers) of doing that?

Cheers,

Jeff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux