On 29/1/20 8:43 μ.μ., Michael Lewis wrote:
If the new value does not overlap with any existing, allow. If it does
overlap, then it must be fully contained by the existing element, or
the existing element must be fully contained by it. Else, reject. Is
that right?
Exactly.
Perumal Raj writes:
> I have used pg_upgrade which runs "analyze_new_cluster.sh" as post upgrade
> activity across all DB on cluster.
pg_upgrade itself won't run that script, it only creates it for you
to run.
> Also, I have executed manual vacuum on all individual tables. However the
> behavior
On 1/29/20 1:58 PM, Perumal Raj wrote:
Hi Tom /Adrian,
Issue is not specific to a table or particular Query. Also there is no
change in DB parameter after upgrade.
You obviously are seeing some difference, so pick a query and do an
EXPLAIN ANALYZE on it. Without some actual performance data
Hi Peter,
I strongly i agree,
I have used pg_upgrade which runs "analyze_new_cluster.sh" as post upgrade
activity across all DB on cluster.
Also, I have executed manual vacuum on all individual tables. However the
behavior is same until i disable the above said parameter.
Regards,
Raj
On Wed,
On 2020-01-29 09:39:03 -0800, Perumal Raj wrote:
> We have recently upgraded postgres from 9.2 to 11.6 and started seeing
> performance issue immediately and able to fix the performance issue after
> disabling parameter: enable_seqscan.
How did you upgrade?
If your upgrade involved a dump and re
Hi Tom /Adrian,
Issue is not specific to a table or particular Query. Also there is no
change in DB parameter after upgrade.
That the only way i can make it most of the the query to run as like before
upgrade.
Note:
Some web reference says , Engine will take some time to adjust until it
runs aut
If the new value does not overlap with any existing, allow. If it does
overlap, then it must be fully contained by the existing element, or the
existing element must be fully contained by it. Else, reject. Is that right?
On 1/29/20 8:12 AM, Achilleas Mantzios wrote:
Hello Dear Postgresql ppl,
I have a table with date ranges and need to express the following
constraint : allow overlaps only if there is complete containment, e.g.
allow values in rows like :
[2020-01-01,2020-01-31)
[2020-01-02,2020-01-10)
[2020-01
Perumal Raj writes:
> We have recently upgraded postgres from 9.2 to 11.6 and started seeing
> performance issue immediately and able to fix the performance issue after
> disabling parameter: enable_seqscan.
> Question :
> Should i keep the above parameter always disabled ? If not why the behavio
On 1/29/20 9:39 AM, Perumal Raj wrote:
Hi All,
We have recently upgraded postgres from 9.2 to 11.6 and started seeing
performance issue immediately and able to fix the performance issue
after disabling parameter: enable_seqscan.
Question :
Should i keep the above parameter always disabled ?
Hi All,
We have recently upgraded postgres from 9.2 to 11.6 and started seeing
performance issue immediately and able to fix the performance issue after
disabling parameter: enable_seqscan.
Question :
Should i keep the above parameter always disabled ? If not why the behavior
changed in Higher v
Hello Dear Postgresql ppl,
I have a table with date ranges and need to express the following constraint :
allow overlaps only if there is complete containment, e.g.
allow values in rows like :
[2020-01-01,2020-01-31)
[2020-01-02,2020-01-10)
[2020-01-10,2020-01-20)
but disallow rows like
[2020-0
On Wed, Jan 29, 2020 at 11:24 PM Julian Backes wrote:
> we only had the "too many shared too many dynamic shared memory segments"
> error but no segmentation faults. The error started occurring after upgrading
> from postgres 10 to postgres 12 (server has 24 cores / 48 threads, i.e. many
> para
On Wed, Jan 29, 2020 at 10:37 PM Nicola Contu wrote:
> This is the error on postgres log of the segmentation fault :
>
> 2020-01-21 14:20:29 GMT [] [4]: [108-1] db=,user= LOG: server process
> (PID 2042) was terminated by signal 11: Segmentation fault
> 2020-01-21 14:20:29 GMT [] [4]: [1
Hi,
we only had the "too many shared too many dynamic shared memory segments"
error but no segmentation faults. The error started occurring after
upgrading from postgres 10 to postgres 12 (server has 24 cores / 48
threads, i.e. many parallel workers). The error itself was not that much of
a proble
This is the error on postgres log of the segmentation fault :
2020-01-21 14:20:29 GMT [] [4]: [108-1] db=,user= LOG: server process
(PID 2042) was terminated by signal 11: Segmentation fault
2020-01-21 14:20:29 GMT [] [4]: [109-1] db=,user= DETAIL: Failed
process was running: select pid
On Wed, Jan 22, 2020 at 4:06 AM Nicola Contu wrote:
> after a few months, we started having this issue again.
> So we revert the work_mem parameter to 600MB instead of 2GB.
> But the issue is still there. A query went to segmentation fault, the DB went
> to recovery mode and our app went to read
Hello, may I ask you for a feedback?
Thanks a lot
Il giorno mar 21 gen 2020 alle ore 17:14 Nicola Contu <
nicola.co...@gmail.com> ha scritto:
> We also reverted this param :
>
> cmdv3=# show max_parallel_workers_per_gather;
> max_parallel_workers_per_gather
> -
>
18 matches
Mail list logo
