От: Ron Johnson
Тема: Re: Tuning PostgreSQL
Дата: ,
Msg-id: 1059511115.7508.197.camel@haggis
(см: обсуждение, исходный текст)
Ответ на: Re: Tuning PostgreSQL  ("scott.marlowe")
Ответы: Re: Tuning PostgreSQL, pt 2  (Ron Johnson)
Список: pgsql-performance

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

Tuning PostgreSQL  ("Alexander Priem", )
 Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
 Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
  Re: Tuning PostgreSQL  (Ang Chin Han, )
   Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
    Re: Tuning PostgreSQL  (Ang Chin Han, )
     Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
    Re: Tuning PostgreSQL  ("Alexander Priem", )
  Re: Tuning PostgreSQL  (Ron Johnson, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Ron Johnson, )
   Re: Tuning PostgreSQL  (Andrew McMillan, )
    Re: Tuning PostgreSQL  ("Arjen van der Meijden", )
     Re: Tuning PostgreSQL  (Tom Lane, )
     Re: Tuning PostgreSQL  ("Balazs Wellisch", )
      Re: Tuning PostgreSQL  (Josh Berkus, )
 Re: Tuning PostgreSQL  ("Roman Fail", )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Josh Berkus, )
    Re: Tuning PostgreSQL  (Vincent van Leeuwen, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Vincent van Leeuwen, )
    Re: Tuning PostgreSQL  (Bruno Wolff III, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Andrew Sullivan, )
   Re: Tuning PostgreSQL  ("Jim C. Nasby", )
    Re: Tuning PostgreSQL  ("scott.marlowe", )
     Re: Tuning PostgreSQL  (Greg Stark, )
      Re: Tuning PostgreSQL  (Ron Johnson, )
     Re: Tuning PostgreSQL  (Vivek Khera, )
      Re: Tuning PostgreSQL  (Ron Johnson, )
       Re: Tuning PostgreSQL  ("scott.marlowe", )
        Re: Tuning PostgreSQL  (Ron Johnson, )
         Re: Tuning PostgreSQL  ("scott.marlowe", )
          Re: Tuning PostgreSQL  (Ron Johnson, )
           Re: Tuning PostgreSQL  ("scott.marlowe", )
            Re: Tuning PostgreSQL  (Ron Johnson, )
             Re: Tuning PostgreSQL, pt 2  (Ron Johnson, )
          Re: Tuning PostgreSQL  (Vivek Khera, )
      Re: Tuning PostgreSQL  (Will LaShell, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Ron Johnson, )
  Re: Tuning PostgreSQL  (Vivek Khera, )
 'View'-performance  ("Alexander Priem", )
  Re: 'View'-performance  (Tom Lane, )

On Tue, 2003-07-29 at 15:09, scott.marlowe wrote:
> On 29 Jul 2003, Ron Johnson wrote:
>
> > On Tue, 2003-07-29 at 14:00, scott.marlowe wrote:
> > > On 29 Jul 2003, Ron Johnson wrote:
> > >
> > > > On Tue, 2003-07-29 at 11:18, scott.marlowe wrote:
> > > > > On 29 Jul 2003, Ron Johnson wrote:
> > > > >
> > > > > > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
> > > > > > > >>>>> "GS" == Greg Stark <> writes:
> > > > > > >
> > > > > > > GS> "scott.marlowe" <> writes:
[snip]
> > > But that's seq scan.  For many database applications, random access
> > > performance is much more important.  Imagine 200 people entering
> > > reservations of 8k or less each into a transaction processing engine.
> > > Each transactions chance to hit an unoccupied spindle is what really
> > > counts.  If there's 30 spindles, each doing a stripe's worth of access all
> > > the time, it's likely to never flood the channel.
> > >
> > > If random access is 1/4th the speed of seq scan, then you need to multiply
> > > it by 4 to get the number of drives that'd saturate the PCI bus.
> >
> > Maybe it's just me, but I've never seen a purely TP system.
>
> I think most of them are running under TPF on a mainframe in a basement
> somewhere, like for airline reservations.  I've never worked on one, but
> met one of the guys who runs one, and they use 12 mainframes for 6 live
> machines and each live machine has a failover machine behind it in sysplex
> mode.  I kept thinking of the giant dinosaurs in Jurassic park...

We have something similar running on Alphas and VMS; does about
8M Txn/day.  Anyone who uses E-ZPass in the northeast eventually
gets stuck in our systems.

(Made me fear Big Brother...)

> > Even if roll off the daily updates to a "reporting database" each
> > night, some yahoo manager with enough juice to have his way still
> > wants up-to-the-minute reports...
>
> Just because it's TP doesn't mean it doesn't have real time reporting.
> But expensive reports probably do get run at night.

Yes, but...  There's always the exception.

> > Better yet, the Access Jockey, who thinks s/he's an SQL whiz but
> > couldn't JOIN himself out of a paper bag...
>
> I've seen a few who got joins and unions and what not, but explaining fks
> or transactions got me a glazed look... :-)

Wow!  They understood joins?  You lucky dog!!!

--
+-----------------------------------------------------------------+
| Ron Johnson, Jr.        Home:              |
| Jefferson, LA  USA                                              |
|                                                                 |
| "I'm not a vegetarian because I love animals, I'm a vegetarian  |
|  because I hate vegetables!"                                    |
|    unknown                                                      |
+-----------------------------------------------------------------+




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

От: Tom Lane
Дата:
Сообщение: Re: Why performance improvement on converting subselect to a function ?
От: Rajesh Kumar Mallah
Дата:
Сообщение: Re: Why performance improvement on converting subselect to a function ?