Not sure if I follow why this is a problem. Seems like it would be
beneficial to have both BEFORE and AFTER COMMIT triggers.
With the BEFORE COMMIT trigger you would have the ability to 'un-
commit' (rollback) the transaction. With
the AFTER COMMIT trigger you wouldn't have that option because
Hello, postgresql 7.4.8 on SuSE Linux here.
I have a table called DMO with a column called ORA_RIF defined as
"timestamp without time zone" ;
I created an index on this table based on this column only.
If I run a query against a text literal the index is used:
> explain select * from dmo whe
I'll let you in on a secret: NOTIFY is actually a before-commit
operation. This is good enough because it never, or hardly ever,
fails. I would argue that anything you want to do in an AFTER COMMIT
trigger could just as well be done in a BEFORE COMMIT trigger; if
that's
not reliable enough th
Hi
I have a cursor that fetches 150K rows and updates or
inserts a table with 150K rows.
It takes several minutes for the process to complete (about
15 minutes). The select by itself (without cursor) gets all rows in 15 seconds.
Is there a way to optimize the cursor to fetch all
create temporary table c_chkpfw_hr_tr_updates as
select * from c_chkpfw_hr_tr a
where exists(select 1 from
chkpfw_tr_hr_dimension b
WHERE a.firstoccurrence
= b.firstoccurrence
Explain analyze on the select statement
that is the basis for temp table data takes forever. I turned off enable_seqscan
but it did not have an effect
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sriram Dandapani
Sent: Monday, April 17, 2006 11:37
AM
To: Pgsql-
"Sriram Dandapani" <[EMAIL PROTECTED]> writes:
> [ query snipped ]
> This takes forever (I have to cancel the statement each time)
How long did you wait?
> c_chkpfw_hr_tr has same indexes as chkpfw_tr_hr_dimension
Which would be what exactly? What does EXPLAIN show for that SELECT?
(I won't mak
Explain output. I tried explain analyze but pgadmin froze after 10
minutes.
QUERY PLAN
"Seq Scan on c_chkpfw_hr_tr a (cost=0.00..225975659.89 rows=11000
width=136)"
" Filter: (subplan)"
" SubPlan"
"-> Bitmap Heap Scan on chkpfw_tr_hr_dimension b
(cost=1474.64..10271.13 rows=1 width=0)"
"
Got an explain analyze output..Here it is
"Seq Scan on c_chkpfw_hr_tr a (cost=0.00..225975659.89 rows=11000
width=136) (actual time=2.345..648070.474 rows=22001 loops=1)"
" Filter: (subplan)"
" SubPlan"
"-> Bitmap Heap Scan on chkpfw_tr_hr_dimension b
(cost=1474.64..10271.13 rows=1 width=
This is one thing that I always try to avoid, a single INSERT INTO...SELECT ...FROM or single UPDATE is always faster compared to looping the same within a cursor, unless its inevitable.
regards,
Luckys.
On 4/17/06, Sriram Dandapani <[EMAIL PROTECTED]> wrote:
Hi
I have a cursor that fetches
10 matches
Mail list logo
