On Thu, 2010-12-30 at 10:45 -0500, Tom Lane wrote:
> Comments?
Thanks for working on this. I love the reuse of tuple flags; I can't
help feeling that opens up doors, just not sure how yet...
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Train
Tom Lane writes:
> I can't get all *that* excited about complicating hash joins as
> proposed. The query is still fundamentally going to be slow because
> you won't get out of having to seqscan the large table. The only way
> to make it really fast is to not read all of the large table, and
> ne
On Thu, Dec 30, 2010 at 11:50 PM, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane wrote:
> > I had an epiphany about this topic, or actually two of them.
> >
> > 1. Whether or not you think there's a significant performance reason
> > to support hash right joins, there's a functi
Robert Haas writes:
> On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane wrote:
>> ... But we only need one bit, so what about commandeering
>> an infomask bit in the tuple itself? For the initial implementation
>> I'd be inclined to take one of the free bits in t_infomask2. We could
>> actually get aw
On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane wrote:
> I had an epiphany about this topic, or actually two of them.
>
> 1. Whether or not you think there's a significant performance reason
> to support hash right joins, there's a functionality reason. The
> infrastructure for right join could just a
I had an epiphany about this topic, or actually two of them.
1. Whether or not you think there's a significant performance reason
to support hash right joins, there's a functionality reason. The
infrastructure for right join could just as easily do full joins.
And AFAICS, a hash full join would o
On Wed, Dec 29, 2010 at 3:58 PM, Simon Riggs wrote:
> On Wed, 2010-12-29 at 09:59 -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs
> wrote:
> > >> It's not a bug, that's the way it currently works. We don't need a
> test
> > >> case for that.
> >
On Wed, 2010-12-29 at 09:59 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wrote:
> >> It's not a bug, that's the way it currently works. We don't need a test
> >> case for that.
>
> > Oh, you're right. I missed the fact that it's a left join.
>
>
- Original Message -
From: "Tom Lane"
To: "Robert Haas"
Cc: "Simon Riggs" ; "Jie Li" ;
"pgsql-hackers"
Sent: Wednesday, December 29, 2010 10:59 PM
Subject: Re: [HACKERS] small table left outer join big table
> Robert Haas wr
i Jie
- Original Message -
From: "Robert Haas"
To: "Simon Riggs"
Cc: "Jie Li" ; "pgsql-hackers"
Sent: Wednesday, December 29, 2010 8:59 PM
Subject: Re: [HACKERS] small table left outer join big table
On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wrote
- Original Message -
From: "Alvaro Herrera"
To: "Robert Haas"
Cc: "Jie Li" ; "pgsql-hackers"
Sent: Wednesday, December 29, 2010 8:39 PM
Subject: Re: [HACKERS] small table left outer join big table
> Excerpts from Robert Haas's mess
Robert Haas writes:
> On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wrote:
>> It's not a bug, that's the way it currently works. We don't need a test
>> case for that.
> Oh, you're right. I missed the fact that it's a left join.
The only thing that struck me as curious about it was that the OP
On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs wrote:
> On Wed, 2010-12-29 at 07:17 -0500, Robert Haas wrote:
>> >
>> > Here I have a puzzle, why not choose 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
Excerpts from Robert Haas's message of mié dic 29 09:17:17 -0300 2010:
> On Tue, Dec 28, 2010 at 5:13 AM, Jie Li wrote:
> > Hi,
> >
> > Please see the following plan:
> >
> > postgres=# explain select * from small_table left outer join big_table using
> > (id);
> >
On Wed, 2010-12-29 at 07:17 -0500, Robert Haas wrote:
> >
> > Here I have a puzzle, why not choose 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?
It's not a bug, t
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li wrote:
> Hi,
>
> Please see the following plan:
>
> postgres=# explain select * from small_table left outer join big_table using
> (id);
> QUERY PLAN
> -
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li wrote:
> Hi,
>
> Please see the following plan:
>
> postgres=# explain select * from small_table left outer join big_table
> using (id);
> QUERY PLAN
>
>
>
Hi,
Please see the following plan:
postgres=# explain select * from small_table left outer join big_table using
(id);
QUERY PLAN
Hash Left Join (cost=126408.00..142436.98 rows=371 width
18 matches
Mail list logo
