Re: [NOVICE] Extreme high load averages

От: Martin Foster
Тема: Re: [NOVICE] Extreme high load averages
Дата: ,
Msg-id: 3F0E036F.7080108@ethereal-realms.org
(см: обсуждение, исходный текст)
Ответ на: Re: [NOVICE] Extreme high load averages  ("Shridhar Daithankar")
Список: pgsql-performance

Скрыть дерево обсуждения

Extreme high load averages  (Martin Foster, )
 Re: Extreme high load averages  (Richard Huxton, )
  Re: Extreme high load averages  (Martin Foster, )
   Re: Extreme high load averages  (Tom Lane, )
    Re: Extreme high load averages  (Martin Foster, )
  Re: Extreme high load averages  (Martin Foster, )
   Re: Extreme high load averages  (Dennis Björklund, )
    Re: [NOVICE] Extreme high load averages  (Martin Foster, )
     Re: [NOVICE] Extreme high load averages  ("Shridhar Daithankar", )
      Re: [NOVICE] Extreme high load averages  (Martin Foster, )
       Re: [NOVICE] Extreme high load averages  ("Shridhar Daithankar", )
        Re: [NOVICE] Extreme high load averages  (Martin Foster, )
        Re: [NOVICE] Extreme high load averages  (Martin Foster, )
     Re: [NOVICE] Extreme high load averages  (Sean Chittenden, )
 Re: Extreme high load averages  ("Shridhar Daithankar", )
  Re: Extreme high load averages  (Martin Foster, )
   Re: Extreme high load averages  (Shridhar Daithankar, )
    Re: Extreme high load averages  (Martin Foster, )
     Re: Extreme high load averages  ("scott.marlowe", )
      Re: Extreme high load averages  (Martin Foster, )
      Re: Extreme high load averages  ("Matthew Nuzum", )
       Re: Extreme high load averages  ("scott.marlowe", )

Shridhar Daithankar wrote:
> On 10 Jul 2003 at 0:43, Martin Foster wrote:
>
>>As for creating a new table, that in itself is a nice idea.   But it
>>would cause issues for people currently in the realm.   Their posts
>>would essentially dissapear from site and cause more confusion then its
>>worth.
>
>
> No they won't. Say you have a base table and your current post table is child
> of that. You can query on base table and get rows from child table. That way
> all the data would always be there.
>
> While inserting posts, you would insert in child table. While qeurying you
> would query on base table. That way things will be optimal.
>
>
>>Inheritance would work, but the database would essentially just grow and
>>grow and grow right?
>
>
> Right. But there are two advantages.
>
> 1. It will always contain valid posts. No dead tuples.
> 2. You can work in chuncks of data. Each child table can be dealt with
> separately without affecting other child tables, whereas in case of a single
> large table, entire site is affected..
>
> Deleting 100K posts from 101K rows table is vastly different than deleting 10K
> posts from 2M rows table. Later one would unnecessary starve the table with
> dead tuples and IO whereas in former case you can do create table as select
> from and drop the original..
>
> HTH
>
> Bye
>  Shridhar

While your idea is sound, I can easily report that this is as bad or
even worse then removing thousands of rows at any given point in time.
  Trying to remove a child table, will pretty much guarantee a complete
and total deadlock in the database.

While it's waiting for a lock, it's locking out authenticating users but
allows existing connections to go through.  And considering this goes on
for tens of minutes and people keep piling on requests to the server,
this quickly disintegrates into one hell of a mess.  I.E. requires a
cold boot to get this thing up again.

Perhaps it is more efficient, but until I can remove archived tables
entirely, I do not exactly see a compelling reason to use inheritance.

Also, some questions are not answered from documentation.   Such as are
indexes carried forth, if you call the parent table, or do you have to
re-create them all manually.   And what happens to the primary key
constraints that no longer show up.

Thanks for the tip though.  Just wish it worked better then it does.

    Martin Foster
    Creator/Designer Ethereal Realms
    




В списке pgsql-performance по дате сообщения:

От: Scott Cain
Дата:
Сообщение: force the use of a particular index
От: "Shridhar Daithankar"
Дата:
Сообщение: Postgresql General Bits issue