Re: postgresql and openmosix migration

От: Merlin Moncure
Тема: Re: postgresql and openmosix migration
Дата: ,
Msg-id: 6EE64EF3AB31D5448D0007DD34EEB34101AE73@Herge.rcsinc.local
(см: обсуждение, исходный текст)
Ответ на: postgresql and openmosix migration  ("Bill")
Список: pgsql-performance

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

postgresql and openmosix migration  ("Bill", )
 Re: postgresql and openmosix migration  (Josh Berkus, )
 Re: postgresql and openmosix migration  ("Bill", )
  Re: postgresql and openmosix migration  (Bruno Wolff III, )
  Re: postgresql and openmosix migration  (Richard Welty, )
  Re: postgresql and openmosix migration  ("Matthew Nuzum", )
  Re: postgresql and openmosix migration  (Joe Conway, )
  Re: postgresql and openmosix migration  (Andrew Hammond, )
  Re: postgresql and openmosix migration  (Josh Berkus, )
   Re: postgresql and openmosix migration  (Rod Taylor, )
    Re: postgresql and openmosix migration  (Richard Welty, )
 Re: postgresql and openmosix migration  (<>, )
 Re: postgresql and openmosix migration  ("Merlin Moncure", )

Bill wrote:
> Ok, so maybe someone on this group will have a better idea.  We have a
> database of financial information, and this has literally millions of
> entries.  I have installed indicies, but for the rather
computationally
> demanding processes we like to use, like a select query to find the
> commodity with the highest monthly or annual returns, the computer
> generally
> runs unacceptably slow.  So, other than clustring, how could I achieve
a
> speed increase in these complex queries?  Is this better in mysql or
> postgresql?

This is a very broad question.  Optimizing your SQL to run fast as on
any other database is something of an art form.  This is a very broad
topic that could fill a book.  For example, a common performance killer
is not having enough sort memory for large ordered result sets.

A critical skill is being able to figure out if the planner is
optimizing your queries badly.  Knowing this is a mixture of observation
and intuition that comes with experience.  The absolute best case
performance of a query is roughly defined by the data that is looked at
to generate the result set and the size of the result set itself when
the query is pulling data from the cache.  The cache problem is
compromisable by throwing more money at the problem but a poorly planned
query will run slowly on any hardware.

I would suggest isolating particular problems and posting them to the
list. (explain analyze works wonders).

Merlin


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

От: Laurent Martelli
Дата:
Сообщение: Re: Traduc Party
От: "Shea,Dan [CIS]"
Дата:
Сообщение: Re: after using pg_resetxlog, db lost