Re: eviscerating the parser

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: eviscerating the parser
Дата
Msg-id BANLkTinxWBjL=ZMxXFoDOhpKnTPRDicwNA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: eviscerating the parser  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: eviscerating the parser
Список pgsql-hackers
On Sat, May 21, 2011 at 5:31 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, May 21, 2011 at 7:51 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Another point is that parsing overhead is quite obviously not the
>> reason for the massive performance gap between one core running simple
>> selects on PostgreSQL and one core running simple selects on MySQL.
>> Even if I had (further) eviscerated the parser to cover only the
>> syntax those queries actually use, it wasn't going to buy more than a
>> couple points.
>
> Incidentally, prepared transactions help a lot.  On unpatched master,
> with pgbench -T 300 -S -n:
>
> tps = 10106.900801 (including connections establishing)
> tps = 10107.015951 (excluding connections establishing)

Are you sure that you actually ran that with -M prepared?  The numbers
look suspiciously similar to the ones reported in your original email.

For what it is worth, on my ancient hardware, the patched code is
slower than the unpatched just as often as it is faster, using -n -S
-T 300 on alternations between servers.

Cheers,

Jeff


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: about EDITOR_LINENUMBER_SWITCH
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SSI predicate locking on heap -- tuple or row?