Re: [PERFORM] Simple join doesn't use index

2013-01-28 Thread Merlin Moncure
On Mon, Jan 28, 2013 at 5:43 PM, Alex Vinnik 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. > > QUERY PLAN >

Re: [PERFORM] Simple join doesn't use index

2013-01-28 Thread Filip Rembiałkowski
On Mon, Jan 28, 2013 at 5:43 PM, Alex Vinnik 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 might be not what you r

Re: [PERFORM] Simple join doesn't use index

2013-01-28 Thread Alex Vinnik
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 tim

Re: [PERFORM] Triggers and transactions

2013-01-28 Thread Rosser Schwarz
On Mon, Jan 28, 2013 at 10:54 AM, Craig James 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 do what you need

Re: [PERFORM] Triggers and transactions

2013-01-28 Thread Richard Huxton
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 b

[PERFORM] Triggers and transactions

2013-01-28 Thread Craig James
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 dangerous

Re: [PERFORM] PostgreSQL over internet

2013-01-28 Thread belal hamed
>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 docum