Re: Question on session_replication_role

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: "Anand Kumar, Karthik" <Karthik(dot)AnandKumar(at)classmates(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Question on session_replication_role
Date: 2015-02-03 03:10:24
Message-ID: 54D03C20.4020305@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2/2/15 8:07 PM, Anand Kumar, Karthik wrote:
> 2)When we run the selects on each table separately, the query runs
> really fast. The moment we introduce the join (AND EXISTS), the sql
> takes over 30 seconds.
>
> 3)The explain plan of this query shows that Primary key on
> reg_email_subscriptions and unique index on iru_tags table is being used.
>
> site=# explain(analyze on, verbose on, costs on, buffers on, timing on)
> SELECT DISTINCT it.recipient_id FROM iru.iru_tags it WHERE
> it.recipient_id BETWEEN 758587587 and 968696896 AND it.status = 0
> AND it.last_update_date >= date_trunc('day', now() - interval '90
> days') AND EXISTS (SELECT DISTINCT res.registration_id FROM
> emailsubscription.reg_email_subscriptions res WHERE res.registration_id
> = it.recipient_id AND res.subscription_id = 200400);
>
> QUERY PLAN
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Unique (cost=0.57..290191.08 rows=45 width=8) (actual
> time=89.536..89.536 rows=0 loops=1)

Your EXPLAIN ANALYZE output doesn't show this taking 30 seconds, it
shows it taking 90ms. Please provide an EXPLAIN ANALYZE That actually
demonstrates the problem.

> 1)Did setting session_replication_role to replica before inserting
> (duplicate) records corrupt the primary key or any of the indexes on
> reg_email_subscriptions table?

I don't believe that session_replication_role does anything to affect
indexing, nor do the docs indicate that. I also see nothing indicating
that in the source code (search for SessionReplicationRole).

So if you suddenly started seeing dupes then I think your index is
corrupted.

> 2)If so, should a reindex on the corrupt PK or index identify the
> corruption and report/fix it?

It won't report it, but it would fix it. (Note that it would throw an
error if the data in the table isn't actually unique.)

> 3)Is this even a problem with index/data corruption?

I doubt it, though you certainly could have corruption.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthew Kelly 2015-02-03 03:12:11 Re: [GENERAL] 4B row limit for CLOB tables
Previous Message Jim Nasby 2015-02-03 02:58:14 Re: array in a store procedure in C