On Wed, Apr 28, 2010 at 5:37 AM, Vlad Arkhipov wrote:
> Even if it will be done it does not solve the original issue. If I
> understood you right there is now no any decent way of speeding up the query
>
> select *
> from t2
> join t1 on t1.t = t2.t
> where t1.id = X;
>
> except of the propagating
akp geek, 28.04.2010 16:37:
We have 8.4, which of AUTOVACUUM PARAMETERS can be set to handle individual
table?
All documented here:
http://www.postgresql.org/docs/current/static/sql-createtable.html
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make change
Check out the manual:
http://www.postgresql.org/docs/8.4/static/routine-vacuuming.html#AUTOVACUUM
Cheers,
Ken
On Wed, Apr 28, 2010 at 10:37:35AM -0400, akp geek wrote:
> Hi -
>don't want to side track the discussion. We have 8.4, which of
> AUTOVACUUM PARAMETERS can be set to handle
Hi -
don't want to side track the discussion. We have 8.4, which of
AUTOVACUUM PARAMETERS can be set to handle individual table? I ran into
bloat with small table only. Now the issue is being resolved.
Regards
On Wed, Apr 28, 2010 at 10:20 AM, Thomas Kellerer wrote:
> Rick, 22.04.2010
Rick, 22.04.2010 22:42:
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.
The default values are set for small tables; it is not being run for
large tables.
With 8.4 you can adjust the autovacuum
Robert Haas wrote:
> Rick wrote:
>> Since vacuum just recovers space, that doesn't seem to be nearly
>> as critical for performance?
>
> That doesn't really match my experience. Without regular
> vacuuming, tables and indices end up being larger than they ought
> to be and contain large amount
2010/4/28 Robert Haas :
On Mon, Apr 26, 2010 at 5:33 AM, Cédric Villemain
wrote:
In the first query, the planner doesn't use the information of the 2,3,4.
It just does a : I'll bet I'll have 2 rows in t1 (I think it should
say 3, but it doesn't)
So it divide the estimated number of ro
2010/4/28 Robert Haas :
> On Mon, Apr 26, 2010 at 5:33 AM, Cédric Villemain
> wrote:
>> In the first query, the planner doesn't use the information of the 2,3,4.
>> It just does a : I'll bet I'll have 2 rows in t1 (I think it should
>> say 3, but it doesn't)
>> So it divide the estimated number of
