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
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=
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)"
"
"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 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-
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
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
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
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
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
10 matches
Mail list logo
