Tom Lane wrote:
> Victor Sudakov <vas@sibptus.ru> writes:
> > Tom Lane wrote:
> >> Well, yeah, actually. An ill-advised query will blow out your backend's
> >> memory consumption, potentially leading to a SIGKILL from the dreaded OOM
> >> killer[1] (if you're on Linux), resulting in a backend crash and cluster
> >> restart.
>
> > Why should "SELECT COUNT(*) FROM t" ever consume more than work_mem
> > even if t has 10000 partitions?
>
> Sure, COUNT(*)'s runtime memory consumption is negligible.
> But you're not thinking about overhead --- specifically,
>
> 1. 10000 relcache entries for the base tables.
>
> 2. If you have N indexes per table, N*10000 relcache entries for
> the indexes. (The planner will probably have looked at all those
> indexes, even if it didn't find any use for them.)
>
> 3. 10000 SeqScan plan nodes and associated rangetable entries,
>
> 4. Likewise, 10000 instances of executor per-node state.
>
> 5. 10000 lock table entries (both shared and local lock tables).
>
> 6. Probably a few per-relation things I didn't think of.
I see your point about all that query-related stuff. I hope the
testing of queries in a staging environment should help to detect such
situations.
What about the system catalogs however? Will the extra 10000
tables and 500000 indexes negatively impact the performance of the
system catalogs? Are there any caveats you could think of?
>
> Basically, this is likely to work until it doesn't ...
Oh, this can be said about many things beyond the very trivial.
Unless there are immediately visible and well-known limitations, I
would risk it.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
