On Fri, 2007-11-16 at 12:13 +0100, Tobias Brox wrote:
> [snip] should i use both auto-vacuum and
> > manual-vacuum?
I would say for 8.2 that's the best strategy (which might change with
8.3 and it's multiple vacuum workers thingy).
> That being said, we have some huge tables in our database and
[Gábor Farkas - Fri at 10:40:43AM +0100]
> my question is: is it recommended to use it? or in other words, should i
> only use autovacuum? or it's better to use manual-vacuuming? which one
> is the "way of the future" :) ? or should i use both auto-vacuum and
> manual-vacuum?
Nightly vacuums ar
>>> On Fri, Nov 16, 2007 at 4:01 PM, in message
<[EMAIL PROTECTED]>, "Merlin Moncure"
<[EMAIL PROTECTED]> wrote:
> On Nov 16, 2007 10:56 AM, Brad Nicholson <[EMAIL PROTECTED]> wrote:
>> On Wed, 2007-11-14 at 17:46 -0500, Tom Lane wrote:
>> > Russell Smith <[EMAIL PROTECTED]> writes:
>> > > It is
On Nov 16, 2007 10:56 AM, Brad Nicholson <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-14 at 17:46 -0500, Tom Lane wrote:
> > Russell Smith <[EMAIL PROTECTED]> writes:
> > > It is possible that analyze is not getting the number of dead rows right?
> >
> > Hah, I think you are on to something. ANALY
On Nov 16, 2007 3:36 PM, Josh Trutwin <[EMAIL PROTECTED]> wrote:
> > Agreed. IMHO, there's nothing wrong with nested-loop join as long
> > as it's being used properly.
>
> Can you explain further please? (I'm not disagreeing with you, just
> want to know when nested loops are not used properly -
On Fri, 16 Nov 2007 11:06:11 -0500
"Jonah H. Harris" <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2007 10:56 AM, Dave Dutcher <[EMAIL PROTECTED]> wrote:
> > I don't know about that. There are times when it is the right
> > plan:
>
> Agreed. IMHO, there's nothing wrong with nested-loop join as long
>
In response to Jeff Davis <[EMAIL PROTECTED]>:
> On Sun, 2007-11-11 at 22:59 -0800, adrobj wrote:
> > This is probably a FAQ, but I can't find a good answer...
> >
> > So - are there common techniques to compensate for the lack of
> > clustered/covering indexes in PostgreSQL? To be more specific
> That being said, we have some huge tables in our database and pretty
> much traffic, and got quite some performance problems when the
> autovacuum kicked in and started vacuuming those huge tables, so we're
> currently running without. Autovacuum can be tuned to not touch those
> tables, but we'
On Sun, 2007-11-11 at 22:59 -0800, adrobj wrote:
> This is probably a FAQ, but I can't find a good answer...
>
> So - are there common techniques to compensate for the lack of
> clustered/covering indexes in PostgreSQL? To be more specific - here is my
> table (simplified):
>
> topic_id int
> pos
adrobj wrote:
This is probably a FAQ, but I can't find a good answer...
So - are there common techniques to compensate for the lack of
clustered/covering indexes in PostgreSQL? To be more specific - here is my
table (simplified):
topic_id int
post_id int
post_text varchar(1024)
The most used q
Dimitri wrote:
> Reading this article I'm just happy for them to see progress done on FreeBSD
> :-)
> As well to demonstrate OS parallelism it's not so impressive to see
> 4CPU server results rather 8CPU or 32threaded Niagara... Don't know
> why they did not present similar performance graphs for
This is probably a FAQ, but I can't find a good answer...
So - are there common techniques to compensate for the lack of
clustered/covering indexes in PostgreSQL? To be more specific - here is my
table (simplified):
topic_id int
post_id int
post_text varchar(1024)
The most used query is: SELECT
Craig James wrote:
> Alvaro Herrera wrote:
>> To recap:
>>
>> - your app only does inserts
>> - there has been no rollback lately
>> - there are no updates
>> - there are no deletes
>>
>> The only other source of dead rows I can think is triggers ... do you
>> have any? (Not necessarily on this ta
On Nov 16, 2007 10:56 AM, Dave Dutcher <[EMAIL PROTECTED]> wrote:
> I don't know about that. There are times when it is the right plan:
Agreed. IMHO, there's nothing wrong with nested-loop join as long as
it's being used properly.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1
> -Original Message-
> From: Ow Mun Heng
> Subject: Re: [PERFORM] PostgreSQL vs MySQL, and FreeBSD
>
> Even for Postgresql, nested loops are still evil and hampers
> performance.
I don't know about that. There are times when it is the right plan:
explain analyze select * from table1
On Wed, 2007-11-14 at 17:46 -0500, Tom Lane wrote:
> Russell Smith <[EMAIL PROTECTED]> writes:
> > It is possible that analyze is not getting the number of dead rows right?
>
> Hah, I think you are on to something. ANALYZE is telling the truth
> about how many "dead" rows it saw, but its notion o
hi,
we are moving one database from postgresql-7.4 to postgresql-8.2.4.
we have some cronjobs set up that vacuum the database (some tables more
often, some tables less often). now, in pg82, there is the possibility
of using the autovacuum.
my question is: is it recommended to use it? or in o
On Fri, Nov 16, 2007 at 10:40:43AM +0100, Gábor Farkas wrote:
> we are moving one database from postgresql-7.4 to postgresql-8.2.4.
any particular reason why not 8.2.5?
>
> my question is: is it recommended to use it? or in other words, should i
> only use autovacuum? or it's better to use manua
On Fri, 2007-11-09 at 16:41 +0100, Sebastian Hennebrueder wrote:
> If the queries are complex, this is understable. I had a performance
> review of a Hibernate project (Java Object Relation Mapping) using
> MySQL. ORM produces easily "complex" queries with joins and subqueries.
> MySQL uses neste
19 matches
Mail list logo
