Hi!
I am seeing such errors in logs:
ERROR: trigger "myapp_assignments" for relation "assignments" already exists
STATEMENT:
BEGIN TRANSACTION;
DROP TRIGGER IF EXISTS "myapp_assignments" ON "assignments";
CREATE TRIGGER "myapp_assignments"
AFTER INSERT OR UPDATE OR DELETE ON "assignments"
FOR EA
On 1/5/19 3:59 AM, Mitar wrote:
Hi!
I am seeing such errors in logs:
ERROR: trigger "myapp_assignments" for relation "assignments" already exists
STATEMENT:
BEGIN TRANSACTION;
DROP TRIGGER IF EXISTS "myapp_assignments" ON "assignments";
CREATE TRIGGER "myapp_assignments"
AFTER INSERT OR UPDATE
Good evening,
On a CentOS 7.6 server (Intel Core i7-6700, 64 GB DDR4 RAM, RAID1 SSD) I
run a backend written in PL/pgSQL and Java for a mobile and desktop word
game with the following Linux packages:
postgresql10-server-10.6-1PGDG.rhel7.x86_64
pgbouncer-1.9.0-1.rhel7.x86_64
postgresql-jd
On 1/5/19 1:59 AM, Mitar wrote:
Hi!
I am seeing such errors in logs:
ERROR: trigger "myapp_assignments" for relation "assignments" already exists
STATEMENT:
BEGIN TRANSACTION;
DROP TRIGGER IF EXISTS "myapp_assignments" ON "assignments";
CREATE TRIGGER "myapp_assignments"
AFTER INSERT OR UPDATE
> "AF" == Alexander Farber writes:
AF> Here are the only modified settings in postgresql.conf:
AF> max_connections = 120 # (change requires restart)
AF> work_mem = 8MB # min 64kB
AF> maintenance_work_mem = 128MB # min 1MB
AF> 90% of the backend source code are JSON-emitting
Oh ok, so it is not as simple as eliminating all "Seq Scan" occurrences...
Thank you for replying Andrew -
On Sat, Jan 5, 2019 at 9:18 PM Andrew Gierth
wrote:
That seems slow in itself, even before adding the extra join - the
> explain suggests that you're both short on indexes and you're getti
Hi!
On Sat, Jan 5, 2019 at 9:35 AM Adrian Klaver wrote:
> > How is this possible? If I am inside a transaction, this should work, no?
>
> Works here:
I thought so. This is being run in parallel multiple times by a
benchmarking tool I made. So it is not just done once, but many times
(50x) at alm
