On 9/16/10 12:14 PM, Tom Lane wrote:
> In any case, it's clear that your installation is not operating as
> intended, and as 8.3 does work for me here. Better look for something
> interfering with stats collection.
OK, will do. Thanks!
--
-- Josh Berkus
Josh Berkus writes:
>> It's been pure nonsense in this thread. Please show an example of
>> what's not working.
> 1) Init a postgresql 8.3 with autovacuum disabled.
> 2) Load a backup of a database into that PostgreSQL.
> 3) Check pg_stat_user_tables. n_live_tup for all tables will be 0.
Rea
Le 16/09/2010 20:39, Josh Berkus a écrit :
>
>> It's been pure nonsense in this thread. Please show an example of
>> what's not working.
>
> 1) Init a postgresql 8.3 with autovacuum disabled.
>
> 2) Load a backup of a database into that PostgreSQL.
>
> 3) Check pg_stat_user_tables. n_live_tup
> It's been pure nonsense in this thread. Please show an example of
> what's not working.
1) Init a postgresql 8.3 with autovacuum disabled.
2) Load a backup of a database into that PostgreSQL.
3) Check pg_stat_user_tables. n_live_tup for all tables will be 0.
4) VACUUM ANALYZE the whole dat
On Thu, Sep 16, 2010 at 1:51 AM, Anssi Kääriäinen
wrote:
> Yes, looks like this is the same case. This makes it hard to use views
> having group by in them, as the whole group by part will always be
> executed. Back to planning board then...
>
> I guess my possibilities for pivot views are:
> - c
Franck Routier wrote:
> So I wanted to better understand to what extend using a
> sledgehammer will impact me :-)
Disabling it globally is likely to significantly hurt some queries.
Before resorting to that, you might decrease effective_cache_size,
increase random_page_cost, and (most importa
On 09/16/2010 01:25 AM, Merlin Moncure wrote:
Take a look at this, and the responses. Is it the same case?:
http://www.mail-archive.com/pgsql-performance@postgresql.org/msg21756.html
merlin
Yes, looks like this is the same case. This makes it hard to use views
having group by in them, as th
I have a problem with some simple query:
select version();
PostgreSQL 8.3.8 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.3.2
20081105 (Red Hat 4.3.2-7)
vacuum full bug_t1;
vacuum full bug_t2;
vacuum analyze bug_t1;
vacuum analyze bug_t2;
explain analyze SELECT ze.id ,rr.id FROM bug_t2 AS rr
Thanks Kevin and Samuel for your input.
The point is we already made a lot of tweaking to try to tune postgresql
to behave correctly. I work with Damien, and here is a post he did in
july to explain the kind of problems we have
http://comments.gmane.org/gmane.comp.db.postgresql.performance/25745
Franck Routier wrote:
> I come into cases where the planner under-estimates the number of
> rows in some relations, chooses to go for nested loops, and takes
> forever to complete the request.
People can provide more targeted assistance if you pick one of the
offenders and provide enough infor
Without knowing more about your queries and table structure, it is hard to
say if there is a better solution. But one thing you should probably
consider doing is just finding the queries where disabling nested loops is
verifiably effective and then just disabling nested loops on that connection
be
Hi,
I am confronted with a use case where my database mainly does big
aggregate select (ROLAP), a bunch of batch jobs, and quite few OLTP.
I come into cases where the planner under-estimates the number of rows
in some relations, chooses to go for nested loops, and takes forever to
complete the re
12 matches
Mail list logo
