Due to the asymmetric communication, a bigger data output in a single
packet (the result of using compression on the tunnel) will get sent
without waiting. A smaller packet will delay a bit waiting for some
additional data, which in your case does not come. You may want to
check out this document
If I drop and then recreate a trigger inside of a single transaction, how
does it affect other processes trying to use the same table? Can they just
merrily go along their way using the table, or will they be blocked by an
exclusive lock?
We have a trigger that detects illegal drugs and
On 28/01/13 18:54, Craig James wrote:
If I drop and then recreate a trigger inside of a single transaction,
how does it affect other processes trying to use the same table? Can
they just merrily go along their way using the table, or will they be
blocked by an exclusive lock?
I *think* it
On Mon, Jan 28, 2013 at 10:54 AM, Craig James cja...@emolecules.com wrote:
But if the drop-and-restore-trigger operation blocks all access to the
tables, that's a problem.
Were the triggers in question created with CREATE CONSTRAINT TRIGGER? If
not, ALTER TABLE foo DISABLE TRIGGER USER may
It sure turned out that default settings are not a good fit. Setting
random_page_cost
to 1.0 made query to run in 2.6 seconds and I clearly see that indexes are
being used in explain plan and IO utilization is close to 0.
QUERY PLAN
Sort (cost=969787.23..970288.67 rows=200575 width=8) (actual
On Mon, Jan 28, 2013 at 5:43 PM, Alex Vinnik alvinni...@gmail.com wrote:
It sure turned out that default settings are not a good fit.
do you know pgtune?
it's a good tool for starters, if you want a fast postgres and don't really
want to learn what's behind the scenes.
random_page_cost=1
On Mon, Jan 28, 2013 at 5:43 PM, Alex Vinnik alvinni...@gmail.com wrote:
It sure turned out that default settings are not a good fit. Setting
random_page_cost to 1.0 made query to run in 2.6 seconds and I clearly see
that indexes are being used in explain plan and IO utilization is close to
0.
