On 10/3/06, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
ITL-like approach is more efficient than per-tuple XIDs unless all tuples in a page are locked at the same time. However, MAXTRANS and PCTFREE issues may bother us.
IIRC, the last time I checked Oracle's patents, they pretty much had the ITL covered. So any work in this area would need a significant amount of research. While ITLs are generally better than our current approach, there are often tuning-related issues due to improper settings of initial ITL slots (INITRANS) and freespace. Many times a block doesn't have enough freespace to fulfill MAXTRANS and you'll get contention issues. However, setting INITRANS too high will waste a significant amount of storage space... so you have to really know the application you plan to be running on the database and what hotspots may exist to effectively tune these parameters on a table-by-table basis. Again, it goes back to how much PostgreSQL expects people to become database tuning experts. Oracle lets you modify almost any parameter which is both good and bad. In Oracle, you can easily fix almost any bottleneck if you know enough about the system; whereas PostgreSQL's tuning options are fairly basic and oriented for more generalized use-cases. There are obvious pros/cons to each type of system architecture which, in this case, pretty much relate to design complexity and the amount of end-user training required to make good use of the software. If anyone ever wanted to play with Oracle and understand some of the issues related to their design considerations, running Quest's Spotlight on Oracle while concurrently running Benchmark Factory gives you a nice overview. I haven't played with either tool in about a year and a half now, but I think you can still get trial versions. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | [EMAIL PROTECTED] Iselin, New Jersey 08830 | http://www.enterprisedb.com/ ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
