Is it possible to have the execution of a trigger (or any function) not
block the completion of the statement they are associated with?
A pattern I had hoped to implement was to do a quick update of rows that
signaled they needed attention, and then an async per-row trigger would
come and do the m
>
> Is the 10.3 plan parallelized at all? It's possible that the planner
> thinks a parallel seqscan is faster than a nonparallel indexscan
> (AFAIR, v10 doesn't have parallel indexscan).
>
Its not because its a delete operation, which doesn't support parallel
anything. Interestingly, the plain
>
> Each table in your database has an entry in the pg_class table. Something
> like:
>
> SELECT relallvisible from pg_class where oid = 'build.household'::regclass;
>
> would show you the value, however, I think a problem here is unlikely
> since that would just control the likelihood of an index-
>
> Another possibility is that 10.3 sees the index-only scan as too expensive
> because it thinks most of the table isn't all-visible. Comparing
> pg_class.relallvisible values might be informative.
>
> regards, tom lane
>
I'm happy to try to dig into this one more, howev
Hello all. I'm migrating a database from PG 9.6 to 10.3 and have noticed a
particular query that is performing very badly compared to its 9.6
counterpart.
The plan on 9.6 v 10.3 are effectively identical except in 9.6 the planner
decides to use an index only scan on the primary key and in 10.3 it
>
> You are running the query (DELETE statement) as if the table is not
> partitioned which is causing the server to crash.
>
> Please run that query for each partitions separately in a loop with
> dynamic query and you should see the improvement. It should be pretty quick.
>
>
I understand that I
>
> Can you extract a self-contained test case that uses unreasonable amounts
> of memory? It seems from this trace that the wheels are coming off in
> at least two places, but identifying exactly where is impossible without
> more info.
>
I will try to make a test case. The data in this table i
Hey guys, I am in the middle of testing out a database migration from 9.6
to 10.3. We have a quasi-multi tenant based application and so are
utilizing native partitions on some relations to help improve some
performance.
I was issuing a query on both databases to cleanup some duplicates in
prepar
On Mon, Nov 20, 2017 at 9:36 AM Tom Lane wrote:
> 9.6.what exactly?
>
9.6.5
>
> The only thing I can think of offhand that could create temp files far in
> excess of the actual data volume is if a hash join repeatedly decides that
> it needs to increase the number of hash batches. We have see
