Re: COMMIT NOWAIT Performance Option
От | Jonah H. Harris |
---|---|
Тема | Re: COMMIT NOWAIT Performance Option |
Дата | |
Msg-id | 36e682920702281346l38bceedbpd79f15db90b373fd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: COMMIT NOWAIT Performance Option (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: COMMIT NOWAIT Performance Option
|
Список | pgsql-hackers |
On 2/28/07, Gregory Stark <stark@enterprisedb.com> wrote: > "Jonah H. Harris" <jonah.harris@gmail.com> writes: > > > Which is, of course, how everyone else does it. > > I happen to agree with your conclusion but this line of argument is > exceptionally unconvincing. In fact in this crowd you'll tend to turn people > off and lose people if you say things like that rather than convince anyone of > anything. Rather than reinventing the wheel, it often pays to piggyback on the solutions others in similar situations have encountered. I'm just stating how others provide similar functionality or capabilities. If someone dislikes an idea just because the major vendors have done it that way, that's their own problem. It's up to the community to decide how to proceed given the information at hand. > > Even pages from the last checkpoint would be a killer. > > Hm that's an interesting thought. We only really have to check pages that > would have received a full page write since the last checkpoint. That's the only way I see that it could possibly be acceptable from a time-to-recover performance standpoint. I would still prefer a guc. > Which is pretty poor design. If we implemented a fsck-like tool I would be far > more interested in checking things like "tuples don't overlap" or "hint bits > are set correctly" and so on. Checksums do nothing to protect against software > failures which is the only kind of failure with a good rationale for being in > an external tool. Regardless of whether it's better as a separate tool or in the database itself, they provide a corruption-finding/consistency-checking capability. As far as other checks that could be performed, SQL Server and Oracle do have their own internal structure checks; many of which execute at runtime, not as a separate tool or process. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: