Cory Tucker wrote:
> Is it possible to have the execution of a trigger (or any function) not block
> the
> completion of the statement they are associated with?
Constraint triggers can be deferred to the end of the transaction, but I
am certain that is not what you are looking for.
> A pattern I
Thiemo Kellner wrote:
> I try to use dblink to create a asynchronous logging facility. I have
> the following code
>
> [...]
> perform dblink_send_query(
> V_DBLINK_CONNECTION_NAME,
> V_QUERY
> );
> raise notice '
On Thu, Mar 29, 2018 at 4:01 PM, Ted Filmore wrote:
> What I am really asking to confirm is after describing the situation is it
> reasonable to focus on (in the short term) tuning autovacuum to increase
> performance or does this not make sense given the workload and I should look
> elsewhere?
I
Using mostly default parameters with 9.3 we are seeing reasonable
performance with our heavy transaction-based application.
However, when we are upgraded to 9.6 we are seeing horrible performance
with the same loads using the same hardware.
Gathering the configuration details, but I think I've sp
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
Hi all
I try to use dblink to create a asynchronous logging facility. I have
the following code
-- open the dblink if it does not yet exist
V_DBLINK_CONNECTION_NAME :=
GET_PROPERTY_VALUE_STRING(
I_PROPERTY_NAME => 'DBLINK_CONNECTION_NAME'
>
> 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
Hi,
> Am 29.03.2018 um 10:30 schrieb Gunnar Nick Bluth :
>
> Thus, buffer_alloc is the global count of buffers allocated in the
> cluster. That it appears in the bgwriter statistics is more or less
> coincidental.
But it seems not to be the total shared_buffers used, but the total number of
all
Cory Tucker writes:
> relallvisible has a value of 0 for that table on both databases.
That would result in IOS being estimated at the same cost as a regular
indexscan, I believe, or very close to that anyway.
Is the 10.3 plan parallelized at all? It's possible that the planner
thinks a paralle
I am using http://calculator.s3.amazonaws.com/index.html to calculate the
cost of RDS vs EC2. Assuming that I am going for only a 2 node setup
(master and slave), few questions:
1. In EC2 how do I indicate that I need two nodes so that I can set up
streaming replication between them for HA. Do
>
> 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-
'On 30 March 2018 at 03:21, Cory Tucker wrote:
>> 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.
> I'm happy to try to dig into this one more, ho
>
> 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
David Rowley writes:
> On 29 March 2018 at 18:26, Cory Tucker wrote:
>> 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 does a
>> sequential scan. The problem is the sequential scan is for a table o
Hi,
> Am 29.03.2018 um 10:30 schrieb Gunnar Nick Bluth :
>
> Thus, buffer_alloc is the global count of buffers allocated in the
> cluster. That it appears in the bgwriter statistics is more or less
> coincidental.
So it is the number of shared_buffers used?
This isn’t possible:
postgres=# SELE
Not to come in too late, but have you tried the non-ubuntu:
sudo su
su -m postgres
pg_ctl -D /var/lib/postgresql/9.3/main start
cheers
Ben
On 29 March 2018 at 12:20, Adrian Klaver wrote:
> On 03/28/2018 07:29 PM, Ken Beck wrote:
>
> Comments in line.
>
> The current log is 0 length, and in
Am 28.03.2018 um 23:38 schrieb Alvar Freude:
> Hi all,
>
> Can someone tell me, what the value of buffers_alloc in the pg_stat_bgwriter
> view
> (https://www.postgresql.org/docs/current/static/monitoring-stats.html#PG-STAT-BGWRITER-VIEW)
> is exactly? Is this the amount of shared buffers used b
17 matches
Mail list logo
