Thanks all. Will try upgrading the postgres version.
On Sun, Mar 10, 2024 at 11:44 PM Ron Johnson
wrote:
> On Sun, Mar 10, 2024 at 1:34 PM Greg Sabino Mullane
> wrote:
>
>>
>> On Sat, Mar 9, 2024 at 1:57 PM hassan rafi
>> wrote:
>>
>>> Would upgrading to the latest version of Postgres potentia
Laurenz thanks for the info.
Thomas no I can't.
Original Message
From: Thomas Kellerer [mailto:sham...@gmx.net]
Sent: Sunday, March 10, 2024 at 11:58 UTC
To: pgsql-general@lists.postgresql.org
Subject: Query plans not identical for `id in(1,2,3)` and `(id=1 or id=2 or
id=3)`
I
On 3/10/24 11:34, sud wrote:
On Sun, Mar 10, 2024 at 11:31 PM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
1) The partition will be across one day(24 hours) it is just the times
may confuse people. Per you example 2024-03-07 00:00:00+00 is the same
time as 2024-03-06 1
On Sun, Mar 10, 2024 at 11:31 PM Adrian Klaver
wrote:
> 1) The partition will be across one day(24 hours) it is just the times
> may confuse people. Per you example 2024-03-07 00:00:00+00 is the same
> time as 2024-03-06 19:00:00-05 for EST. The issue is that the +00 and
> -05 maybe ignored. Als
On Sun, Mar 10, 2024 at 1:34 PM Greg Sabino Mullane
wrote:
>
> On Sat, Mar 9, 2024 at 1:57 PM hassan rafi
> wrote:
>
>> Would upgrading to the latest version of Postgres potentially solve the
>> issue?
>>
>
> Potentially, yes, but the only one who can answer that for sure is you.
> Upgrade to 11
On 3/10/24 10:51, sud wrote:
On Sun, Mar 10, 2024 at 10:32 PM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
On 3/10/24 05:12, sud wrote:
>
> In my example in the first post, I see, if someone connected to a
RDS
> Postgres database and run the create partition
On Sun, Mar 10, 2024 at 10:32 PM Adrian Klaver
wrote:
> On 3/10/24 05:12, sud wrote:
> >
> > 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 partit
On Sat, Mar 9, 2024 at 1:57 PM hassan rafi wrote:
> Would upgrading to the latest version of Postgres potentially solve the
> issue?
>
Potentially, yes, but the only one who can answer that for sure is you.
Upgrade to 11.22 and re-run the query. Worst case scenario, it runs the
same speed but yo
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
Hi Experts,
Your input is most welcome!
We are using Postgres 13 (and plan to upgrade to 15 soon). We have logical
replication with about 40 servers subscribing to one publisher. 40 Walsender
processes are running on the publisher server. When we insert a row into a
table holding binary dat
On Sat, Mar 9, 2024 at 3:41 AM Adrian Klaver
wrote:
> On 3/8/24 00:23, sud wrote:
> >
> > Starting a new thread...
> >
> > Something interesting and not sure if its expected behaviour as below.
> > We are also confused a bit here.
> >
> > In the below example we created two partitioned tables on
Ilya Basin schrieb am 09.03.2024 um 20:08:
Hi List.
I have a list of bigint keys and I need to retrieve rows by these keys.
Normally, I would split this list into pages of size 900 and perform several
`SELECT ... WHERE key in($1,$2,...)`. However, the proprietary ORM we use can
only produce t
On Sat, 2024-03-09 at 23:08 +0400, Ilya Basin wrote:
> I have a list of bigint keys and I need to retrieve rows by these keys.
> Normally, I would split this list into pages of size 900 and perform
> several `SELECT ... WHERE key in($1,$2,...)`. However, the proprietary
> ORM we use can only produc
13 matches
Mail list logo
