I had enable_seqscan turned OFF; With enable_seqscan turned ON it takes only 6
minutes to complete
the query and not 44minuts like it did with enable_seqscan turned OFF. THANKS
A LOT!
It's still much more slower than MS SQL server but now it has acceptable times.
Sebastián Baioni
---
Hello, I'm migrating from MS SQL Server to PostgreSQL 8.1 and I have a serious problem:Table: APORTES - Rows: 9,000,000 (9 million)*cuiT (char 11)*cuiL (char 11)*PERI (char 6)FAMI (numeric 6)I need all the cuiLs whose max(PERI) are from a cuiT, and the Max(FAMI) of those cuiLs, so the sentence
Can you provide an EXPLAIN ANALYZE of the query in PG? Have you
analyzed the PG database? How many rows is this query expected to
return? Which version of PG are you running? What indexes have you
defined?
-- Mark
On Tue, 2006-08-15 at 14:38 +, Sebastián Baioni wrote:
Hello, I'm
Hi Nark, thanks for your answer.
It's expected to return 1,720 rows (of 80,471 that match with condition WHERE
T.cuiT='12345678901')
We have indexes by :
uesapt000: cuiT, cuiL, PERI;
uesapt001: cuiL, PERI;
uesapt002: cuiT, PERI;
We usually make a vacuum analyze and reindex of every table, and
On Tue, Aug 15, 2006 at 03:43:29PM +, Sebasti?n Baioni wrote:
Hi Nark, thanks for your answer.
It's expected to return 1,720 rows (of 80,471 that match with condition WHERE
T.cuiT='12345678901')
We have indexes by :
uesapt000: cuiT, cuiL, PERI;
uesapt001: cuiL, PERI;
uesapt002:
On Aug 15, 2006, at 1:53 PM, Sebastián Baioni wrote:
9 - Index Scan using uesapt001 on
APORTES (cost=0.00..37301678.64
rows=9339331 width=25) (actual time=110.000..2520690.000
rows=9335892 loops=1)
It's taking 2520 seconds to scan an index with 9M rows, which
=?iso-8859-1?q?Sebasti=E1n=20Baioni?= [EMAIL PROTECTED] writes:
8- GroupAggregate (cost=0.00..37348395.05 rows=3951
width=25) (actual
time=130.000..2629617.000 rows=254576 loops=1)
9 - Index Scan using uesapt001 on APORTES
