Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9yY9-000600-A3 for pgsql-admin@arkaria.postgresql.org; Wed, 19 Jan 2022 00:10:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n9yY7-0005Np-4V for pgsql-admin@arkaria.postgresql.org; Wed, 19 Jan 2022 00:10:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9yY6-0005Ne-NX for pgsql-admin@lists.postgresql.org; Wed, 19 Jan 2022 00:10:02 +0000 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n9yY4-0003NE-0l for pgsql-admin@lists.postgresql.org; Wed, 19 Jan 2022 00:10:02 +0000 Received: by mail-qt1-x82c.google.com with SMTP id h15so778705qtx.0 for ; Tue, 18 Jan 2022 16:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=ddTi3jZpS2q4cLrsaI05bfD8WwZ6nj8pFePEFlQw4B8=; b=cXvRG+/W2JioGLfbSiwebPoBKesWj/0T2YUJ+zlg9uCKJX2q6SSpMX/ETFF1Ia2xRY V12Raqf/70esVHV/nfLn/Zrt3s1TuOfnpXKZ0GpiDCzoWUQvcRCwNHCMljBUkRG0rtvM Lm56cSGyxRtWogPNBDog4KkjkpaXwuGPUecH0BwDkLXHeTi9/B80TOEi/sHHxsOUAk28 xk+KeozEDhje5Tg7MIfQ/BLgqPdbfG0g8tTeJFpUSxYrlGKGEHwJOyhNeSiy/d0bIguH 8Be8KjQits9Gb5rdVSs+qkNmh+gzPbxFKQ1FFgDns/Rwqtsc1jB3pS6zOFXbNKQ5pj2y 8K0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=ddTi3jZpS2q4cLrsaI05bfD8WwZ6nj8pFePEFlQw4B8=; b=sCEwc7gTsaEbTgo6jClYMlW0NvYA5S6SHjCKKoF76OjzB5Q4WBS5HmmNiepcwtj8E/ j1NZqWZ0hfAdEMvpO6QJ185I8xgVSyyZZiEFvXAKA6nF4knBU+twvVwTwIQT4J3+oi+R tdTa7qwixPFl3CGBJs6WJ1ABheb5+wBbsOSIvfz+xWf8f+9uH59LqqZnTwGGw2yid/TE CCPqHQ/dYeXoHQwbjkdT9qJ7rKn9yDdFaaibsuRQtQfGxnXHlSZFgzxueQDKxKdQuFh2 +VWll/hkQhilg4XFsr++ObGfCqjaoF4g7GcPxuSBFSUGL3l6sW/VTEwhat/jhld6CIeZ T5DQ== X-Gm-Message-State: AOAM5333zX5RN6ySsVN4/VfFMevHLW91U01VWjPEq+BvejaDWh95aNSQ AC0T00zAfu6m5uCC9408G03eXBY1zwo= X-Google-Smtp-Source: ABdhPJy4m13sVL+DzovUHo4eoBVNJDbLCr8bmlSz6OZ1UK+ua0QNp93IN64kVT50ivLBB5050zuQdg== X-Received: by 2002:a05:622a:1482:: with SMTP id t2mr23079179qtx.416.1642550997204; Tue, 18 Jan 2022 16:09:57 -0800 (PST) Received: from [192.168.2.100] (pool-72-79-19-93.nwrknj.east.verizon.net. [72.79.19.93]) by smtp.gmail.com with ESMTPSA id g22sm11515556qtk.23.2022.01.18.16.09.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jan 2022 16:09:56 -0800 (PST) Content-Type: multipart/alternative; boundary="------------SSgkGFtnVwr0crRcGn5IvJFC" Message-ID: <0fdfb200-9aad-370b-3282-6585158de94f@gmail.com> Date: Tue, 18 Jan 2022 19:09:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Large number of partitions of a table Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: <3919502.1642393668@sss.pgh.pa.us> <671340a5-1960-e5dc-1d09-4b7f36cda2c8@gmail.com> <254601.1642480213@sss.pgh.pa.us> <268771.1642489687@sss.pgh.pa.us> From: Mladen Gogala In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------SSgkGFtnVwr0crRcGn5IvJFC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/18/22 09:47, Ron wrote: > EXPLAIN plans are going to be hilariously gigantic, which means that > query planning would take a loooong time,  And the query planner (in > v12, at least) can generate some pretty bad plans in partitioned > tables; I bet there are edge cases in the QP code that don't work well > with 10000 partitions and 50000 indices. These things sometimes happen. On the oracle-l, there is a thread in progress about a generated SQL with 130,000 lines which fails parsing because parsing exhausts the available memory. In such cases, I am less inclined to look for a fault with the database software and more inclined to inflict an unusual and cruel punishment on whoever has designed the data model. -- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com --------------SSgkGFtnVwr0crRcGn5IvJFC Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/18/22 09:47, Ron wrote:
EXPLAIN plans are going to be hilariously gigantic, which means that query planning would take a loooong time,  And the query planner (in v12, at least) can generate some pretty bad plans in partitioned tables; I bet there are edge cases in the QP code that don't work well with 10000 partitions and 50000 indices.

These things sometimes happen. On the oracle-l, there is a thread in progress about a generated SQL with 130,000 lines which fails parsing because parsing exhausts the available memory. In such cases, I am less inclined to look for a fault with the database software and more inclined to inflict an unusual and cruel punishment on whoever has designed the data model.

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--------------SSgkGFtnVwr0crRcGn5IvJFC--