On 11/28/23 18:13, Owen Nelson wrote:
> Aurora is not really Postgres
Oh geez, I didn't realize there was such a divide. This is my first look
at Aurora and I thought it was just a hosted postgres offering.
> Aurora is not really Postgres
Oh geez, I didn't realize there was such a divide. This is my first look at
Aurora and I thought it was just a hosted postgres offering.
Still, I'll take what I can get. Hopefully, some of this will carry over.
Owen Nelson writes:
>> Are your ANALYZE stats up to date on this table?
> It's a very good question! Right now, I'm taking it on faith that
> autovacuum and autoanalyze are keeping things up to date, but if I'm honest
> I've been getting some conflicting information from pg_stat_user_tables and
Embarrassed to say that it's been so long since I participated in a mailing
list I neglected to ensure my replies were directed back at the list rather
than select individuals.
I'll recap what I shared for the list here, for posterity.
@Boris
This is where the iteration aspect is tricky. I don't
On Wed, 29 Nov 2023 at 11:23, Owen Nelson wrote:
> "message_payload_not_null_pidx" btree (expiration) WHERE payload IS NOT
> NULL
> I periodically run a query like this:
> ```
> UPDATE message SET payload = NULL WHERE id IN (
> Update on message (cost=1773.41..44611.36 rows=5000
Owen Nelson writes:
> The hope is the sub-select would leverage the index
> "message_payload_not_null_pidx" but when I `EXPLAIN ANALYZE` the query, I
> see a seq scan instead.
I think your problem is the horrid rowcount misestimation here:
> -> Seq Scan on
Hi!
I've got a query running periodically which has been degrading in
performance as time goes on. I'm hoping to better understand what the
contributing factors are.
Given a table with:
```
postgres=# \d message
Table "public.message"
Column |
On 2023-11-28 13:12 +0100, Dominique Devienne wrote:
> Hi. I've got a nice little POC using PostgreSQL to implement a REST API
> server.
> This uses json_agg(t) to generate the JSON of tables (or subqueries in
> general),
> which means I always get back a single row (and column, before I added the
On 11/28/23 08:46, CG wrote:
Hi fellow list members. I hit a brick wall with my last question. I'd
like to try this again.
I need to remove OIDs from tables without locking the tables for long
periods of time. I have developed a strategy that seems to work, but I
would like the experts to
I think you are just trying to get the number of columns in the underlying
table, no real cost to read the metadata
select count(id), (select count(attrelid) from pg_attribute where attrelid=
't1'::regclass and attnum>0) , json_agg(t) from t1 t;
select count(id), (select count(attrelid) from
Hi fellow list members. I hit a brick wall with my last question. I'd like to
try this again.
I need to remove OIDs from tables without locking the tables for long periods
of time. I have developed a strategy that seems to work, but I would like the
experts to weigh in since I'm planning on
Hello,
we test database migration to new db servers from version 12 to 15 and a
problem with logical replication stopped us.
In the current code (PGSQL ver 12), we use a function with SECURITY DEFINER
for refreshing subscriptions:
---
DECLARE
BEGIN
execute 'alter subscription ' || sSubName ||
Not equivalent to the use of NOT ARRAY and entirely possible I have
misunderstood the requirement ...do you have some more test cases the non
array solution does not work for
Regards
Hector Vass
07773 352559
On Mon, Nov 27, 2023 at 9:29 AM Dominique Devienne
wrote:
> On Sat, Nov 25, 2023 at
Hi. I've got a nice little POC using PostgreSQL to implement a REST API
server.
This uses json_agg(t) to generate the JSON of tables (or subqueries in
general),
which means I always get back a single row (and column, before I added the
count(t.*)).
But I'd like to get statistics on the number of
At Mon, 27 Nov 2023 19:58:13 +0100, Laurenz Albe
wrote in
> On Mon, 2023-11-27 at 11:50 +, Sri Mrudula Attili wrote:
> > ERROR: could not access status of transaction 16087052
> > DETAIL: Could not read from file "pg_subtrans/00F5" at offset 122880:
> > Success.
By the way, just out of
15 matches
Mail list logo
