On Wed, Dec 7, 2011 at 5:13 PM, Havasvölgyi Ottó
wrote:
> So there seems to be something on this Debian machine that hinders
> PostgreSQL to perform better. With 8.4 I logged slow queries (with 9.1 not
> yet), and almost all were COMMIT, taking 10-20-30 or even more ms. But at
> the same time the
Well thought it was maybe just going from 8.4.4 to 9.1.1 so upgraded
to 8.4.9 and tried pg_upgrade again (this is 64bit) and it's failing
-bash-4.0$ /tmp/pg_upgrade --check --old-datadir "/data/db"
--new-datadir "/data1/db" --old-bindir "/ipix/pgsql/bin" --new-bindir
"/ipix/pgsql9/bin"
Performing
Thanks for that Mario, I will check it out.
@All:
Anyway, I have compiled 9.1.2 from source, and unfortunately the
performance haven't got better at the same load, it is consistently quite
low (~70 ms average transaction time with 100 clients) on this Debian. I am
quite surprised about this, it is
Hi,
On 8 December 2011 02:15, Christiaan Willemsen wrote:
> Currently, we are running into serious performance problems with our
> paritioning setup, because index lookups are mostly done on allpartions, in
> stead of the one partition it should know that it can find the needed row.
Planner is n
On Wed, Dec 7, 2011 at 8:34 AM, Anibal David Acosta wrote:
> Hello, I have a postgres 9.0.2 installation.
>
> Every works fine, but in some hours of day I got several timeout in my
> application (my application wait X seconds before throw a timeout).
>
> Normally hours are not of intensive use, so
>From my last report I had success but it was successful due to lots of
manual steps. I figured it may be safer to just create a new rpm,
installing to pgsql9 specific directories and a new data directory.
This allows pg_upgrade to complete successfully (so it says). However
my new data directory
Hello, I have a postgres 9.0.2 installation.
Every works fine, but in some hours of day I got several timeout in my
application (my application wait X seconds before throw a timeout).
Normally hours are not of intensive use, so I think that the autovacuum
could be the problem.
Is threre any l
Hi there,
Currently, we are running into serious performance problems with our
paritioning setup, because index lookups are mostly done on allpartions, in
stead of the one partition it should know that it can find the needed row.
Simple example, were we have a partitioned tables
Josh Berkus wrote:
> On 12/5/11 1:36 PM, Kevin Grittner wrote:
>> I understand the impulse to run autovacuum less frequently or
>> less aggressively. When we first started running PostgreSQL the
>> default configuration was very cautious.
>
> The default settings are deliberately cautious, as de
On Mon, Dec 5, 2011 at 14:14, Thiago Godoi wrote:
> My original query :
>
> select table1.id
> from table1, (select function(12345) id) table2
> where table1.kind = 1234
> and table1.id = table2.id
>
> "Nested Loop (cost=0.00..6.68 rows=1 width=12)"
> " Join Filter: ()"
> " -> Seq Scan on reco
On 12/07/2011 09:23 AM, Havasvölgyi Ottó wrote:
> Thanks, Josh.
> The only reason I tried 8.4 first is that it was available for Debian as
> compiled package, so it was simpler for me to do it. Anyway I am going
> to test 9.1 too. I will post about the results.
>
If you're using squeeze, you can
On 12/06/2011 09:00 PM, Tom Lane wrote:
> Mario Splivalo writes:
>> I have 8.4.8 on producion and 8.4.9 on test, could that explain the
>> difference in plans chosen?
>
> I'd wonder first if you have the same statistics settings on both.
> The big problem here is that the estimation of the join s
Thanks, Josh.
The only reason I tried 8.4 first is that it was available for Debian as
compiled package, so it was simpler for me to do it. Anyway I am going to
test 9.1 too. I will post about the results.
Best reagrds,
Otto
2011/12/7 Josh Berkus
> On 12/6/11 4:30 PM, Havasvölgyi Ottó wrote:
>
13 matches
Mail list logo
