Re: [PERFORM] Process 11812 still waiting for ExclusiveLock on extension of relation

On Jul 18, 2012, at 5:08 AM, Sergey Konoplev wrote: > Hi, > > On Tue, Jul 17, 2012 at 7:57 PM, David Kerr wrote: >> I suspect that this is related to a sustained heavy load that would stop >> autovacuum from >> getting at this table... Does that sound plausible? > > Well, not sure. Let us loo

Re: [PERFORM] optimizing queries using IN and EXISTS

Nick Hofstede writes: > I'm surprised at the difference in speed/execution plan between two logically > equivalent queries, one using IN, the other using EXISTS. (At least I think > they are logically equivalent) > SELECT * > FROM foo > WHERE 'text6' IN (SELECT value >FRO

Re: [PERFORM] optimizing queries using IN and EXISTS

I realize there is a case where IN returns NULL and EXISTS returns FALSE (in case there is a matching bar with bar.value set to NULL) In that case however, this would result in the foo row not being included in the resultset, which is the same outcome in both cases. NOT IN vs NOT EXISTS is anothe

Re: [PERFORM] Sequencial scan in a JOIN

On Tue, Jun 5, 2012 at 8:48 AM, Andrew Jaimes wrote: > Hi everyone, > > I am trying to run the following query: > > SELECT count(1) --DISTINCT l_userqueue.queueid > FROM e_usersessions > JOIN l_userqueue > ON l_userqueue.userid = e_usersessions.entityid > JOIN a_activity > ON a_acti

Re: [PERFORM] Array fundamentals

On Sat, Jun 2, 2012 at 1:05 PM, idc danny wrote: > Hi all, > I got 2 complementary functions, which will do opposite things. > 1 - CombineStrings(stringarray character varying[]) RETURNS character > varying > This one will take as parameter an array of strings and will return a string > with some

Re: [PERFORM] optimizing queries using IN and EXISTS

On 18 July 2012 17:10, Nick Hofstede wrote: > Hi, > > I'm surprised at the difference in speed/execution plan between two logically > equivalent queries, one using IN, the other using EXISTS. (At least I think > they are logically equivalent) They are not logically equivalent. http://www.postg

[PERFORM] optimizing queries using IN and EXISTS

Hi, I'm surprised at the difference in speed/execution plan between two logically equivalent queries, one using IN, the other using EXISTS. (At least I think they are logically equivalent) I've created a small setup that illustrates what I mean. Consider the following tables: CREATE TABLE foo

Re: [PERFORM] PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.

On Tue, Jul 3, 2012 at 10:22 AM, Stanislaw Pankevich wrote: > Hello, > > My question below is almost exact copy of the on on SO: > http://stackoverflow.com/questions/11311079/postgresql-db-30-tables-with-number-of-rows-100-not-huge-the-fastest-way > > The post on SO caused a few answers, all as on

[PERFORM] monitoring suggestions

PostgreSQL: 9.1 OS: Red Hat 6 This PostgreSQL instance is used for dynamic web content. It runs on a dedicated server. So I need some PostgreSQL monitoring advice. There are two basic strategies that I am aware of for configuring PostgreSQL: 1) In Memory: With an in memory option you g

[PERFORM] postgresql query cost values/estimates

Hi, I was wondering if there are any recommended ways or tools for calculating the planner cost constants? Also, do the absolute values matter or is it simply the ratio between them? I'm about to configure a new server and can probably do a rough job of calculating them based on supposed speeds

Re: [PERFORM] Process 11812 still waiting for ExclusiveLock on extension of relation

Hi, On Tue, Jul 17, 2012 at 7:57 PM, David Kerr wrote: > I suspect that this is related to a sustained heavy load that would stop > autovacuum from > getting at this table... Does that sound plausible? Well, not sure. Let us look at the table's statistics first. \x select * from pg_stat_user_t