| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Pyhalov <alp(at)sfedu(dot)ru> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL memory usage |
| Date: | 2019-10-17 12:40:15 |
| Message-ID: | 20765.1571316015@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Alexander Pyhalov <alp(at)sfedu(dot)ru> writes:
> However, one table has 2250 partitions and I've seen several selects to this table (based on the primary key of individual partitions) with a huge IN () list (about 500 keys). Don't expect this to be efficient, but unsure that these queries caused such memory consumption.
Yeah, it could be that it's just the number of partitions involved in
the query that's causing the memory bloat. v10 is not bright about
pruning uninteresting partitions from a query (v12 is better), so
there will be 2250 tables involved so far as the planner and executor
are concerned. And then if you've got a large/complex WHERE clause,
that's probably copied and modified for each of those tables :-(.
We don't generally recommend having more than a hundred or so partitions,
because of issues like this. v12 is starting to make it feasible to have
more, but only in limited use-cases.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Erwin Brandstetter | 2019-10-17 13:13:24 | Re: Can functions containing a CTE be PARALLEL SAFE? |
| Previous Message | Alexander Pyhalov | 2019-10-17 12:29:04 | RE: PostgreSQL memory usage |