Re: Question related to partitioning with pg_partman

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Question related to partitioning with pg_partman
Дата
Msg-id 46b8c853-a98c-41ee-b3f3-e1fcf11f26db@aklaver.com
обсуждение исходный текст
Ответ на Re: Question related to partitioning with pg_partman  (sud <suds1434@gmail.com>)
Ответы Re: Question related to partitioning with pg_partman
Список pgsql-general
On 3/10/24 05:12, sud wrote:
> 

> 
>     '2024-03-07 00:00:00+00' and '2024-03-06 19:00:00-05' are the same time
>     as is '2024-03-07 00:00:00-05' and '2024-03-07 05:00:00+00'.
> 
>     Still I would think for sanity sake you would want to stick with UTC.
> 
> 
> 
> Thank you so much Adrian.
> 
> In my example in the first post, I see, if someone connected to a RDS 
> Postgres database and run the create partition command using pg_partman 
> by setting the timezone as "UTC", the 7th march partition looks to be 
> spanned from "7th march midnight" to "8th march midnight", when queried 
> the partition_experession from the data dictionary view. Which is correct.
> 
> And same information if someone querying by setting the timezone as EST 
> is showing spanning from "6th march 7PM" to "7th March 7PM". And this 
> can cause sometimes the partition may shift to other days all together. 
> Similar differences happen if creating the partitions using EST timezone 
> initially and then querying the data dictionary from UTC timezone.

The above is at odds with your example below which has the correct values:

2024-03-07 00:00:00+00 = 2024-03-06 19:00:00-05

> 
> So my question was, if in these types of scenarios, we should follow a 
> standard approach of setting the timezone as UTC in such a type of 
> global user use case, while the system can persist data from multiple 
> users sitting across different time zones? So that the boundary(start 
> and end time) of each of the range partitions will be set as consistent 
> in one timezone across all the partitioned tables?

You need to first determine what your time frames are going to be?

1) Midnight to Midnight in UTC will be consistent when viewed in UTC. It 
will not be when viewed in other time zone +/- the offset from UTC.

2) Or Midnight to Midnight in the users time zone, in which case the UTC 
values will differ.

You have to decide which of the above is your goal. The bottom line is 
by definition the local wall clock time will not equal UTC, GMT 
excepted. This comes down to what the purpose of the partitions are? In 
other words how do you want to organize the data?

> 
> And even while inserting the data , should we set the timezone to first 
> UTC and do the data load ?



> 
> ******* Partition created by pg_partman by setting timezone as UTC 
> ***************
> 
> *UTC*
> *Partition_name                         Partition_expression*
> test_timestamp_p2024_03_07 FOR VALUES FROM ('2024-03-07 00:00:00+00') TO 
> ('2024-03-08 00:00:00+00')
> 
> when queried the partition_expression using EST ..
> 
> *EST*
> *Partition_name                         Partition_expression*
> test_timestamp_p2024_03_07 FOR VALUES FROM ('2024-03-06 19:00:00-05') TO 
> ('2024-03-07 19:00:00-05')
> 
> 
> ******* Partition created by pg_partman by setting timezone as EST 
> ***************
> 
> *EST*
> *Partition_name                         Partition_expression*
> test_timestamp2_p2024_03_07 FOR VALUES FROM ('2024-03-07 00:00:00-05') 
> TO ('2024-03-08 00:00:00-05')
> 
> when queried the partition_expression using UTC ..
> 
> *UTC*
> *Partition_name                         Partition_expression*
> test_timestamp2_p2024_03_07 FOR VALUES FROM ('2024-03-07 05:00:00+00') 
> TO ('2024-03-08 05:00:00+00')
> 
> *******
> 
> Also i see both the "setting" and "reset_val" is showing as local 
> timezone only. If we set the timezone to a different value than the 
> local timezone then it gets updated on the "setting".
> 
> Regards
> Sud

-- 
Adrian Klaver
adrian.klaver@aklaver.com




В списке pgsql-general по дате отправления:

Предыдущее
От: Avi Weinberg
Дата:
Сообщение: walsender RAM increases by 500 MB while data is 80 MB
Следующее
От: Greg Sabino Mullane
Дата:
Сообщение: Re: Seeing high query planning time on Azure Postgres Single Server version 11.