On Tue, Apr 1, 2025 at 9:28 AM David G. Johnston
wrote:
> On Mon, Mar 31, 2025 at 8:39 PM Jayadevan M
> wrote:
>
>> Hello PG members,
>> I used 'IST' in a query like this - * (timestamp_hour) at time zone
>> 'IST' time_ist *and did not get the expected output - timestamp in
>> Indian Standard T
Jayadevan M writes:
> I used 'IST' in a query like this - * (timestamp_hour) at time zone 'IST'
> time_ist *and did not get the expected output - timestamp in Indian
> Standard Time.
I think IST defaults to 'Israel Standard Time', a/k/a Asia/Jerusalem,
a/k/a UTC+2. To get it to mean Indian Stan
On Mon, Mar 31, 2025 at 8:39 PM Jayadevan M
wrote:
> Hello PG members,
> I used 'IST' in a query like this - * (timestamp_hour) at time zone
> 'IST' time_ist *and did not get the expected output - timestamp in Indian
> Standard Time. So I queried the 2 views that provide timezone info and did
>
Hello PG members,
I used 'IST' in a query like this - * (timestamp_hour) at time zone 'IST'
time_ist *and did not get the expected output - timestamp in Indian
Standard Time. So I queried the 2 views that provide timezone info and did
not really understand the abbrev column.
select name, abbrev, u
> On Mar 31, 2025, at 10:54, Eden Aharoni wrote:
>
> So you believe it's strictly an EBS issue?
Well, PostgreSQL certainly can read faster than 34MB/s off of disk. With the
data you've given, I can't really say if it's purely an EBS issue.
> On Mar 31, 2025, at 06:54, Eden Aharoni wrote:
> Is this expected IO read rate? I can’t help but feel we’re missing something
> here..
Really, no particular I/O rate is "expected": if PostgreSQL needs that much
data, it'll use that much I/O to get it. From your description, it's likely
t
On Mon, Mar 31, 2025 at 9:42 AM Renan Alves Fonseca
wrote:
> I'm not sure if we should mention the fix or if we should mention a
> workaround...
>
Workarounds are ok but my observation is that "this may change in the
future" comments are pointless and should be stricken from the manual
because p
Laurenz Albe writes:
> On Mon, 2025-03-31 at 18:41 +0200, Renan Alves Fonseca wrote:
>> I would add another Note below like:
>> "Except when inlined, an SQL function is always executed with a
>> generic plan. This behavior may not be desired in some situations, and
>> it will be fixed in future ve
> On Mar 31, 2025, at 10:32, Eden Aharoni wrote:
>
> First, thanks for the reply :)
> So, I do know which part is taking a lot of IO time and it's to be honest any
> node that reads from the disk.. of course, we're running EXPLAIN on our
> queries (to be more specific we use auto_explain) bu
Hi all,
Hopefully, someone here could help us understand whats going on with our
deployment..
We are running Postgres 17.4 on AWS RDS on an ec2 instance that has:
* 32vCPU
* 128GB RAM
* gp3 with 25K IOPS and 4000MiB/s throughput
* the instance supports up to 3125GB/s of throughput
On Mon, 2025-03-31 at 18:41 +0200, Renan Alves Fonseca wrote:
> I would add another Note below like:
> "Except when inlined, an SQL function is always executed with a
> generic plan. This behavior may not be desired in some situations, and
> it will be fixed in future versions."
But that is not tr
On Mon, Mar 31, 2025 at 5:10 AM David Rowley wrote:
>
> On Sat, 29 Mar 2025 at 10:30, Renan Alves Fonseca
> wrote:
> > Currently, in the SQL function path the plan is always generic. The
> > planner ignores the function arguments. The plan_cache_mode setting
> > has no effect in this path.
> >
>
On 3/31/25 06:54, Eden Aharoni wrote:
Hi all,
Hopefully, someone here could help us understand whats going on with our
deployment..
We are running Postgres 17.4 on AWS RDS on an ec2 instance that has:
* 32vCPU
* 128GB RAM
* gp3 with 25K IOPS and 4000MiB/s throughput
* the instance su
On Sun, 2025-03-30 at 22:10 -0700, David G. Johnston wrote:
> On Sunday, March 30, 2025, 이현진 wrote:
> > Since PostgreSQL uses MVCC, I'm wondering what the best practice is for
> > non-blocking reads,
> > and whether there's an equivalent to dirty reads or READ UNCOMMITTED.
>
> https://www.postg
14 matches
Mail list logo
