Tom, Gregory,
Thank you for your replies. I will try reindexing the table but I am not
very sure that will make any difference.
The reason is that when I built the table, I was building it making sure
there are unique values that get trown into it, in addition to the
constraint defined in the table.
THere is a pgplsql function that says something like:
for s in select distinct suid from migratek.stuides loop
insert (...,suid) values (...,s.suid) into migratek.mt
So right from the start, there should be no duplications.
Hmm... maybe this will help: in the same function (i.e. transaction), I am
also doing an update on the same table, using suid as update key, that is:
update migratek.mt set sdate = smth where suid = s.suid;
Can this - performing an update on a table from within the (same) table
populating transaction that was not yet commited - throw off postgress in
some way? Especially given the large number of tuples inserted (2.7
million)
Right now, my inclination is to rewrite the function, separating the
updates from the inserts and see if that works.
Razvan
> Gregory Stark <stark@xxxxxxxxxxxxxxxx> writes:
>> "Razvan Costea-Barlutiu" <cbrazvan@xxxxxxxxxx> writes:
>>> This has way too many ramifications for me to follow so I do appreciate
>>> some
>>> guidance.
>
>> What do the outputs of these queries say?
>
> It would also be interesting to know whether REINDEXing the table
> succeeds and if so whether the behavior gets any saner.
>
> regards, tom lane
>
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
