Gregory Stark wrote:
"Richard Huxton" <[EMAIL PROTECTED]> writes:
Paul Lambert wrote:
" -> Sort (cost=30197.98..30714.85 rows=206748 width=16) (actual >>
time=5949.691..7018.931 rows=206748 loops=1)"
"Sort Key: dealer_id, year_id, subledger_id, account_id"
"Sort Method: e
Paul Lambert wrote:
"-> Merge Join
(cost=35.56..19732.91 rows=12 width=48) (actual time=0.841..2309.828
rows=206748 loops=1)"
I'm no expert, but in the interests of learning: why is the
rows estimate so far out for this join?
Thanks,
Jeremy
--
> Also, try replacing the DISTINCT with GROUP BY. The code path for DISTINCT
> unfortunately needs a bit of cleaning up and isn't exactly equivalent to GROUP
> BY. In particular it doesn't support hash aggregates which, if your work_mem
> is large enough, might work for you here.
Sorry, strike th
"Richard Huxton" <[EMAIL PROTECTED]> writes:
> Paul Lambert wrote:
>
>> " -> Sort (cost=30197.98..30714.85 rows=206748 width=16) (actual >>
>> time=5949.691..7018.931 rows=206748 loops=1)"
>> "Sort Key: dealer_id, year_id, subledger_id, account_id"
>> "Sort Method: external me
Paul Lambert wrote:
Paul Lambert wrote:
This part of the query alone takes a significant part of the time:
SELECT DISTINCT ON (finbalance.dealer_id, finbalance.year_id,
finbalance.subledger_id, finbalance.account_id)
finbalance.year_id AS year,
finbalance.dealer_id
Paul Lambert wrote:
This part of the query alone takes a significant part of the time:
SELECT DISTINCT ON (finbalance.dealer_id, finbalance.year_id,
finbalance.subledger_id, finbalance.account_id)
finbalance.year_id AS year,
finbalance.dealer
I have a query that looks like this:
SELECT DISTINCT ON (EEFSCode)
eefsbase.company||eefsbase.department||eefsbase.branch||eefsbase.franchise||eefsbase.subledger||eefsbase.account
AS EEFSCode,
eefsbase.company AS company_code,
eefsbase.branch AS bran
