Re: Another idea for dealing with cmin/cmax

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: "Greg Stark" <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Another idea for dealing with cmin/cmax
Date: 2006-10-06 13:39:04
Message-ID: 36e682920610060639x14491a93v5c07e63c25033837@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/3/06, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> 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 | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2006-10-06 14:05:01 Re: Upgrading a database dump/restore
Previous Message Andrew Dunstan 2006-10-06 12:40:53 Re: pg_dump exclusion switches and functions/types