nner-indexscan is the only plan type with a hope of
> doing that.
>
> regards, tom lane
Yes there is no index on the joined column, otherwise
nestloop-with-inner-indexscan should be preferred.
But why can't outer join be as clever as inner join? Anyway, if we
unfortunately
Thank you for all your comments.
I think the condition of this optimization is whether the small table can fit
into memory. If not, then it doesn't work since two tables still need to be
written to disk. But if yes, we can save all I/O costs in the hash join
process.
Thanks,
L
se the small table to build hash table?
>> > It
>> > can avoid multiple batches thus save significant I/O cost, isn't it?
>>
>> Yeah, you'd think. Can you post a full reproducible test case?
>
> Also, what version is this?
>
> --
> Álvaro Herrera
&
n really so expensive? Does it incur additional I/O? From the cost
model, it seems not, all the "cost" are the same (575775.45).
Thanks,
Li Jie
- Original Message -
From: "Kenneth Marshall"
To: "Jie Li"
Cc: "pgsql-hackers"
Sent: Thursday, Decem
same I/O costs, why should there be so much difference?
Thanks,
Li Jie
- Original Message -
From: "Marti Raudsepp"
To: "Jie Li"
Cc: "pgsql-hackers"
Sent: Thursday, December 23, 2010 10:17 PM
Subject: Re: [HACKERS] Why is sorting on two columns so slower tha
- Original Message -
From: "Kenneth Marshall"
To: "Li Jie"
Cc: "pgsql-hackers"
Sent: Thursday, December 23, 2010 10:30 PM
Subject: Re: [HACKERS] Why is sorting on two columns so slower thansortingon
one column?
> On Thu, Dec 23, 2010 at 10:19:46
Hi all,
I'm interested in this parallel project,
http://wiki.postgresql.org/wiki/Parallel_Query_Execution
But I can't find any discussion and current progress in the website, it
seems to stop for nearly a year?
Thanks,
Li Jie
--
Sent via pgsql-hackers mailing list (pgs
