Skip site navigation (1) Skip section navigation (2)

Re: Instability in TRUNCATE regression test

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>,pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Instability in TRUNCATE regression test
Date: 2006-06-28 17:18:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jun 28, 2006 at 01:13:42PM -0400, Tom Lane wrote:
> One thing I was toying with was to add an index to pg_constraint on,
> say, (confrelid, conrelid), and to replace the existing seqscans for FK
> constraints with scans using this index.  The second-column ordering
> would guarantee everybody visits the entries in the same order.  Not
> sure about overall performance implications ... in a small database,
> several indexscans might take more time than one seqscan.

In a small database, both operations are likely to be plenty fast for
TRUNCATE, though. Surely the performance impact of getting the requisite
locks would far exceed any catalog scan times, no? And if you were doing
TRUNCATE's very often, I'd expect the right pages to be in cache
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to

pgsql-hackers by date

Next:From: A.M.Date: 2006-06-28 17:18:39
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Previous:From: markDate: 2006-06-28 17:14:16
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as primary keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group