Re: [PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

2016-02-08 Thread Hedayat Vatankhah
Hi again, /*Hedayat Vatankhah*/ wrote on Sun, 31 Jan 2016 01:20:53 +0330: Hi, /*David Rowley*/ wrote on Sun, 31 Jan 2016 04:57:04 +1300: On 31 January 2016 at 01:30, Hedayat Vatankhah wrote: Personally, I expect both queries below to perform exactly the same: SELECT

Re: [PERFORM] gin performance issue.

2016-02-08 Thread Marc Mamin
> -Original Message- > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Sent: Freitag, 5. Februar 2016 16:07 > > http://explain.depesz.com/s/wKv7 > > Postgres Version 9.3.10 (Linux) > > > > Hello, > > this is a large daily table that only get bulk inserts (200-400 /days) with > > no

[PERFORM] Primary key index suddenly became very slow

2016-02-08 Thread Gustav Karlsson
Hi, Question: What may cause a primary key index to suddenly become very slow? Index scan for single row taking 2-3 seconds. A manual vacuum resolved the problem. Background: We have a simple table ‘KONTO’ with about 600k rows. Column|Type |

Re: [PERFORM] Primary key index suddenly became very slow

2016-02-08 Thread Gustav Karlsson
Additional information: The problematic row has likely received many hot updates (100k+). Could this be a likely explanation for the high execution time? Regards, Gustav On Feb 8, 2016, at 10:45 AM, Gustav Karlsson > wrote: Hi,

Re: [PERFORM] bad COPY performance with NOTIFY in a trigger

2016-02-08 Thread Merlin Moncure
On Sat, Feb 6, 2016 at 6:03 AM, Filip Rembiałkowski wrote: > Thanks for the feedback. > > This patch is my first and obvious approach. > > @Merlin, I'm not sure if I get your idea: > - keep previous behaviour as obligatory? (which is: automatic > de-duplicating of

Re: [PERFORM] Bitmap and-ing between btree and gin?

2016-02-08 Thread Jeff Janes
On Thu, Feb 4, 2016 at 9:19 AM, Jordi wrote: The custom here is to respond in line, not to top-post. Thanks. > > So basically you're saying it's hard to do sorting in any way when a gin > index is involved? Neither with a complete multi-column btree_gin index > because

Re: [PERFORM] gin performance issue.

2016-02-08 Thread Jeff Janes
On Mon, Feb 8, 2016 at 2:21 AM, Marc Mamin wrote: > > - auto vacuum will not run as these are insert only tables > - according to this post, auto analyze would also do the job: > > http://postgresql.nabble.com/Performance-problem-with-gin-index-td5867870.html > It seems

Re: [PERFORM] bad COPY performance with NOTIFY in a trigger

2016-02-08 Thread Merlin Moncure
On Mon, Feb 8, 2016 at 8:35 AM, Merlin Moncure wrote: > On Sat, Feb 6, 2016 at 6:03 AM, Filip Rembiałkowski > wrote: >> Thanks for the feedback. >> >> This patch is my first and obvious approach. >> >> @Merlin, I'm not sure if I get your idea: