Re: How are locks managed in PG?
От | Scott Marlowe |
---|---|
Тема | Re: How are locks managed in PG? |
Дата | |
Msg-id | dcc563d10812212002x7b602011y8098416bce2e1b9e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How are locks managed in PG? ("Jonah H. Harris" <jonah.harris@gmail.com>) |
Ответы |
Re: How are locks managed in PG?
Re: How are locks managed in PG? Re: How are locks managed in PG? |
Список | pgsql-general |
On Sun, Dec 21, 2008 at 8:48 PM, Jonah H. Harris <jonah.harris@gmail.com> wrote: > On Sun, Dec 21, 2008 at 9:42 PM, David Fetter <david@fetter.org> wrote: >> On Sun, Dec 21, 2008 at 08:46:15PM -0500, Jonah H. Harris wrote: >>> On Fri, Dec 19, 2008 at 7:49 AM, Alvaro Herrera >>> <alvherre@commandprompt.com> wrote: >>> >> Oracle on the other hand stores the lock information directly in >>> >> the data block that is locked, thus the number of locks does not >>> >> affect system performance (in terms of managing them). >>> >> >>> >> I couldn't find any description on which strategy PG applies. >>> > >>> > None of the above. We're smarter than everyone else. >>> >>> Which is why Oracle's locks are more scalable than PG's? >> >> You've been talking about your super-secret test which you allege, >> quite implausibly, I might add, to have Oracle (8i, even!) blowing >> PostgreSQL's doors off for weeks now. >> >> Put up, or shut up. > > Same to the standard PG B.S. responses such as, "None of the above. > We're smarter than everyone else." When's the last time Alvaro used > or tuned Oracle? Does he have a clue about how Oracle locks scale? > Stop complaining. The difference is HE put forth an opinion about the pg developers being smarter, but you put forth what seems like a statement of fact with no evidence to back it up. One is quite subjective and open for debate on both sides, and often to good effect. The other is a statement of fact regarding scalability in apparently all usage circumstances, since it wasn't in any way clarified if you were talking about a narrow usage case or all of the possible and / or probably ones. Having dealt with cust service for a few commercial dbs, I can safely say I get way better service from way smarter people when I have a problem. And I don't have a lot of problems.
В списке pgsql-general по дате отправления: