Re: [PERFORM] tmpfs and postgres memory

2010-04-26 Thread Greg Spiegelberg
On Mon, Apr 26, 2010 at 5:24 PM, Anj Adu wrote: > I have a 16G box and tmpfs is configured to use 8G for tmpfs . > > Is a lot of memory being wasted that can be used for Postgres ? (I am > not seeing any performance issues, but I am not clear how Linux uses > the tmpfs and how Postgres would be af

[PERFORM] tmpfs and postgres memory

2010-04-26 Thread Anj Adu
I have a 16G box and tmpfs is configured to use 8G for tmpfs . Is a lot of memory being wasted that can be used for Postgres ? (I am not seeing any performance issues, but I am not clear how Linux uses the tmpfs and how Postgres would be affected by the reduction in memory) Sriram -- Sent via p

Re: [PERFORM] autovacuum strategy / parameters

2010-04-26 Thread Alvaro Herrera
Rick wrote: > So, in a large table, the scale_factor is the dominant term. In a > small > table, the threshold is the dominant term. But both are taken into > account. Correct. > The default values are set for small tables; it is not being run for > large tables. So decrease the scale factor an

Re: [PERFORM] Planner issue on sorting joining of two tables with limit

2010-04-26 Thread Tom Lane
=?KOI8-R?B?68/Sz9TLz9cg4czFy9PBzsTS?= writes: > So PostgreSQL planner can produce the plan I need but it doesn't produce > this plan when I specify particular second ordering column. Well, no, because that plan wouldn't produce the specified ordering; or at least it would be a lucky coincidence i

[PERFORM] Planner issue on sorting joining of two tables with limit

2010-04-26 Thread Коротков Александр
Hello, everybody! I'm using PostgreSQL 8.4.3, compiled by Visual C++ build 1400, 32-bit on Windows XP SP3. I use following data model for issue reproducing. CREATE TABLE test1 ( id integer NOT NULL, "value" double precision, CONSTRAINT test1_pkey PRIMARY KEY (id) ); CREATE INDEX test1_valu

Re: [PERFORM] autovacuum strategy / parameters

2010-04-26 Thread Rick
On Apr 22, 2:55 pm, robertmh...@gmail.com (Robert Haas) wrote: > On Wed, Apr 21, 2010 at 11:06 AM, Rick wrote: > > I have a DB with small and large tables that can go up to 15G. > > For performance benefits, it appears that analyze has much less cost > > than vacuum, but the same benefits? > > Err

Re: [PERFORM] Optimization idea

2010-04-26 Thread Cédric Villemain
2010/4/26 Vlad Arkhipov : > >> On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov >> wrote: >> >>> >>> I don't think this is just an issue with statistics, because the same >>> problem arises when I try executing a query like this: >>> >> >> I'm not sure how you think this proves that it isn't a prob