Re: general PG network slowness (possible cure) (repost)

Поиск
Список
Период
Сортировка
От Peter T. Breuer
Тема Re: general PG network slowness (possible cure) (repost)
Дата
Msg-id 200705251402.l4PE2LN01473@inv.it.uc3m.es
обсуждение исходный текст
Ответ на Re: general PG network slowness (possible cure) (repost)  (Richard Huxton <dev@archonet.com>)
Ответы Re: general PG network slowness (possible cure) (repost)  (Richard Huxton <dev@archonet.com>)
Re: general PG network slowness (possible cure) (repost)  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-performance
"Also sprach Richard Huxton:"
> I'm not sure you really want a full RDBMS. If you only have a single
> connection and are making basic key-lookup queries then 90% of
> PostgreSQL's code is just getting in your way. Sounds to me like gdbm

Yep - I could happily tell it not to try and compile a special lookup
scheme each time, for example!  (how that?). I could presumably also
help it by preloading the commands I will run and sending over the
params only with a "do a no. 17 now!".

> (or one of its alternatives) is a good match for you. Failing that,
> sqlite is probably the next lowest-overhead solution.

Not a bad idea. but PG _will_ be useful when folk come to analyse the
result of the analyses being done. What is slow is getting the data
into the database now via simple store, fetch and update.

> Of course, if you want to have multiple clients interacting and
> performing complex 19-way joins on gigabyte-sized tables with full-text

Well, the dbs are in the tens of MB from a single run over a single
file (i.e analysis of a single 30KLOC source).  The complete analysis
space is something like 4000 times that, for 4300 C files in the linux
kernel source. And then there is all the linux kernel versions. Then
there is godzilla and apache source ..

> indexing and full transaction control then you *do* want a RDBMS.

We want one anyway. The problem is filling the data and the simple
fetch and update queries on it.

I really think it would be worthwhile getting some developer to tell me
where the network send is done in PG.

Peter

В списке pgsql-performance по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13))
Следующее
От: Bastian Voigt
Дата:
Сообщение: Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13))