Re: Increasing the length of pg_stat_activity.current_query...

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Increasing the length of pg_stat_activity.current_query...
Дата
Msg-id 877joxl6il.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Increasing the length of pg_stat_activity.current_query...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Increasing the length of  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> > I'd vote in favour of relaxing the limit entirely, as Sean suggests.
> 
> The choice is not between "limit" and "no limit", it is between
> "limit" and "broken".

What do you think is broken about fragmented UDP packets?

Once Upon a Time fragmented UDP packets basically didn't work at all. But
that's going on 20 years now. These days you can reliably send large packets
up to 32k certainly over local connections and even over long-haul connections
when you don't have packet loss problems. Even when you do the worst case
scenario is your packet doesn't make it, so what's the harm in at least trying
to send it?

I'm assuming the packets aren't a fixed size. As long as we aren't bumping up
the other packets to 8k then there's no danger to sending the occasional 8k
packet. 

The reason people don't like fragmented UDP packets is that there's no
retransmission facility and a packet is lost if a single fragment is lost. So
if you're sending an 8k packet with an MTU of 1500 you'll have 5 fragments.
With 10% packet loss that gives your 8k fragmented packet a 50/50 chance of
getting through.

But if you're having 10% packet loss on your local area network you already
have a problem. Even then you're losing 10% of your smaller queries and 50% of
your larger queries whereas currently you would be losing 10% of your smaller
queries and 100% of your larger queries...

-- 
greg



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_resetxlog options
Следующее
От: Gaetano Mendola
Дата:
Сообщение: Bittorrent