Re: Question on overall design

From: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
To: Chris Travers <chris(dot)travers(at)gmail(dot)com>
Cc: Dominique Devienne <ddevienne(at)gmail(dot)com>, veem v <veema0000(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Question on overall design
Date: 2023-12-12 04:53:34
Message-ID: CANzqJaCQTA5Om-rm0LBVVORWRY9pWp8EHfDhHpM7nXpZGo_zNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Dec 11, 2023 at 10:34 PM Chris Travers <chris(dot)travers(at)gmail(dot)com>
wrote:

> On Tue, Dec 12, 2023 at 2:11 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
> wrote:
>
>> On Mon, Dec 11, 2023 at 4:41 AM Dominique Devienne <ddevienne(at)gmail(dot)com>
>> wrote:
>>
>>> On Sun, Dec 10, 2023 at 5:56 PM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
>>> wrote:
>>>
>>>> * We departitioned because SELECT statements were *slow*. All
>>>> partitions were scanned, even when the partition key was specified in the
>>>> WHERE clause.
>>>>
>>>
>>> Surely that's no the case on newer PostgreSQL, is it? Otherwise what's
>>> the point of partitioning?
>>> Also, I remember reading something about recent improvements with a
>>> large number of partitions, no?
>>>
>>> As someone who's interested on partitioning, I'd appreciate details.
>>> Thanks, --DD
>>>
>>
>> This was on 12.5. v13 was just released, and we weren't confident about
>> running a mission-critical system on a .1 version.
>>
>
> Something's wrong if all partitions are scanned even when the partition
> clause is explicit in the where clause.
>
> There are however some things which can cause problems here, such as type
> casts of the partition key, or when the partition key is being brought in
> from a join.
>

Here's a snippet. part_date (type timestamp without time zone) is the
partition key:

and separation0_.part_date>=to_date('01-Jun-2021', 'DD-Mon-YYYY')
and transmissi1_.part_date>=to_date('01-Jun-2021', 'DD-Mon-YYYY')
and separation0_.part_date=transmissi1_.part_date

>
>> All "transaction" tables were partitioned by month on partion_date, while
>> the PK was table_name_id, partition_date.
>>
>> Queries were _slow_, even when the application knew the partion_date
>> range (since queries might span months). PG just wouldn't prune.
>>
>
> Was there a datatype issue here? Like having a partition key of type
> timestamp, but the query casting from date?
>

The partition key was of type timestamp, while "the right hand side of the
predicate".would be whatever to_char() generated.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2023-12-12 09:50:21 Re: how can I fix my accent issues?
Previous Message Chris Travers 2023-12-12 03:33:55 Re: Question on overall design