Re: Trigger Performance

From: Jasen Betts <jasen(at)xnet(dot)co(dot)nz>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Trigger Performance
Date: 2011-01-17 10:29:45
Message-ID: ih15mp$9jq$1@reversiblemaps.ath.cx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2011-01-16, Randall Smith <randall(at)tnr(dot)cc> wrote:
> Before reading. This is solved. Was an error on my part.
>
> On Sun, 2011-01-16 at 03:46 +0000, Jasen Betts wrote:
>> In plpgsql IF is an implicit select.
>> <http://www.postgresql.org/docs/8.4/interactive/plpgsql-expressions.html>
>>
>> IF EXISTS (SELECT 1 FROM t1 WHERE
>> volume_id = NEW.volume_id AND name = NEW.name) THEN
>> RAISE EXCEPTION '% already exists on volume', NEW.name;
>> END IF;
>
> Thanks. Certainly more concise.
>
>>
>> > 0.053 ms/record / 1,000 ms/sec * 10,000 records = .53 seconds
>>
>> huh?
>>
>> > According to that stat, this lookup should be adding about 0.5 seconds
>> > to 10,000 records,
>>
>> why? what are you doing to 10000 records.
>
> Inserting them. Sorry, that was a critical omission on my part. The
> trigger check is for inserts and I'm testing its performance by
> inserting 10,000 records.

that'll have n.log(n) complexity (or worse) you can't simply multiply by
10000 because each row added to the index slows the average index lookup
time a little.

> Turns out my EXPLAIN ANALYZE times were so low because I was querying
> for a volume_id that had only a few rows. When I query for a volume_id
> with 10,000 rows, it changes to 7 ms, which matches the performance I'm
> seeing. That's acceptable to me because that's probably at the upper
> end of what I'll see. 7 ms to check 10,000 text fields is actually
> impressive to me.

>> how much disk (in bytes, and dollars) are you hoping to save by not
>> using the index.

> I need to be able to fit my indexes in RAM.

why? Indices that don't fit are still useful. Doing 20 or so record
retreivals to confirm the absense of a record is likely to be slower
than doing 5 reads and a write or two to check and update a disk-based
index.

postgres isn't going to blindly load all the indices into ram.

> I need to be able to fit my indexes in RAM. This table will have a few
> billion records These text fields can
> be up to 1k each.

this query will create about 300000 sample records with 1K text
repeat it with dufferent numbers in the first generate_series
10001,20000
20001,30000
etc
until you get 2 billion records

then create your indices and do your testing.

insert into t1 select a::integer as volume_id,
md5((a*b)::text) || md5((a*b+1)::text) || md5((a*b+3)::text)
|| md5((a*b+4)::text) || md5((a*b+5)::text) || md5((a*b+6)::text)
|| md5((a*b+7)::text) || md5((a*b+8)::text) || md5((a*b+9)::text)
|| md5((a*b+11)::text) || md5((a*b+12)::text) || md5((a*b+13)::text)
|| md5((a*b+14)::text) || md5((a*b+15)::text) as name from
(select generate_series( 1 ,10000) as a ,generate_series(1,29) as b) as foo;

--
⚂⚃ 100% natural

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jasen Betts 2011-01-17 10:39:42 Re: Trigger Performance
Previous Message Alexandros Karypidis 2011-01-17 10:28:05 PostgreSQL 9.0.2 hangs during shutdown on Windows (Win32)