On Wed, 7 Sept 2022 at 13:33, Levi Aul wrote:
> To be clear, this isn't a bug report. There is no bug—everything is working
> exactly as it should. The partitions are not being pruned because the
> workload consists of OLAP aggregations that fetch a small number of rows
> spread across all part
We're using Postgres 14.5. I meant partition pruning.
To be clear, this isn't a bug report. There is no bug—everything is working
exactly as it should. The partitions are not being pruned because the
workload consists of OLAP aggregations that fetch a small number of rows
spread across all partiti
On Wed, 7 Sept 2022 at 07:40, Levi Aul wrote:
> In other words, our workload is inherently one that acquires "way too many
> locks." Our largest performance bottleneck, according to pg_wait_sampling, is
> the LockManager itself. Despite most of our queries spending only
> milliseconds actually
"Dirschel, Steve" writes:
> setdatabase | setrole |
>
> setconfig
> -+-+-
We recently upgraded from postgres 12.8 to 14.3. We are running
Aurora Postgres on AWS.
>Aurora Postgres != Postgres. This doesn't seem like something they'd change,
>but we can't rule that out entirely.
>>> Try:
>>> select setting, source, sourcefile, pending_restart from pg_settin
By "SEALED", do you mean "READ ONLY"?
On 9/6/22 14:39, Levi Aul wrote:
My company runs some large OLAP data warehouses with append-only,
time-partitioned datasets. Our workloads involve aggregations and joins,
and query the data in ways not amenable to constraint-exclusion; and we
serve a high
"Dirschel, Steve" writes:
>>> We recently upgraded from postgres 12.8 to 14.3. We are running
>>> Aurora Postgres on AWS.
Aurora Postgres != Postgres. This doesn't seem like something they'd
change, but we can't rule that out entirely.
>> Try:
>> select setting, source, sourcefile, pending_re
>On 9/6/22 12:07, Dirschel, Steve wrote:
>> We recently upgraded from postgres 12.8 to 14.3. We are running
>> Aurora Postgres on AWS.
>>
>> We have procedures that will make calls to RAISE NOTICE to write out
>> messages if you interactively call the procedure through psql. These
>> procedur
On 9/6/22 12:07, Dirschel, Steve wrote:
We recently upgraded from postgres 12.8 to 14.3. We are running Aurora
Postgres on AWS.
We have procedures that will make calls to RAISE NOTICE to write out
messages if you interactively call the procedure through psql. These
procedures are getting ca
My company runs some large OLAP data warehouses with append-only,
time-partitioned datasets. Our workloads involve aggregations and joins,
and query the data in ways not amenable to constraint-exclusion; and we
serve a high concurrent number of these queries at once from a single DB.
In other word
We recently upgraded from postgres 12.8 to 14.3. We are running Aurora
Postgres on AWS.
We have procedures that will make calls to RAISE NOTICE to write out messages
if you interactively call the procedure through psql. These procedures are
getting called by pg_cron.
Since upgrading these RA
On Fri, Sep 2, 2022 at 5:43 PM Christophe Pettus wrote:
>
> > On Sep 2, 2022, at 14:22, Jeffrey Walton wrote:
> > Given the NOTES in the man page, how do we determine if a user and
> > database are present using the shell? Is there another utility we
> > should be using?
>
> pg_isready literally
> On Sep 5, 2022, at 23:10, Karthik K L V wrote:
> The above query fails with the below exception when the value of ?1 resolves
> to null.
> org.postgresql.util.PSQLException: ERROR: operator does not exist: character
> varying = bytea
> Hint: No operator matches the given name and argument
On 9/6/22 02:10, Karthik K L V wrote:
We are migrating from Oracle 12C to Aurora Postgres 13 and running
into query failures when the bind value of a Text datatype resolves to nul
Oracle is actually in the wrong here. Nothing should be equal to null,
ever. There is also different behavior with
As far as I understand, according to the logs, the last leader does not yet
know about the new timeline
and it is trying to download the full log from the previous timeline.
It seems there should be a conflict that the partial file already exists
locally when restoring in this case, but this does
On Tue, Sep 6, 2022, 08:46 Lahnov, Igor wrote:
> What do you think it is possible to add a check to the restore command,
> that a partial or full file already exists?
>
> Or is disabling the restore command a possible solution in this case?
>
My opinion didn't change, pg_probackup does a weird t
16 matches
Mail list logo
