On Sat, 14 Nov 2009, Tom Lane wrote:
Matthew Wakeling writes:
[ discussion about applying materialize to a mergejoin's inner indexscan ]
I have finally gotten round to doing something about this, and applied
the attached patch to CVS HEAD. Could you test it on your problem case
to see what h
Matthew Wakeling writes:
> [ discussion about applying materialize to a mergejoin's inner indexscan ]
I have finally gotten round to doing something about this, and applied
the attached patch to CVS HEAD. Could you test it on your problem case
to see what happens? If it's not convenient to load
On Tue, 18 Aug 2009, Tom Lane wrote:
-> Index Scan using locationbin8000__subjectobjectbin on
locationbin8000 l1
(cost=0.00..71635.23 rows=657430 width=20)
(actual time=0.056..170.857 rows=664588 loops=1)
Index Co
Matthew Wakeling writes:
> -> Index Scan using locationbin8000__subjectobjectbin on
> locationbin8000 l1
> (cost=0.00..71635.23 rows=657430 width=20)
> (actual time=0.056..170.857 rows=664588 loops=1)
> Index Cond:
On Tue, 18 Aug 2009, Tom Lane wrote:
I would be more curious in the poster's situation to turn off
enable_seqscan, enable_sort, and/or enable_nestloop see how the index
scan merge join plan runs.
Like this:
QUERY PLAN
Greg Stark writes:
> If my recollection is right the reason we put the materialize above
> the sort node has to do with Simon's deferred final merge pass
> optimization. The materialize was a way to lazily build the final
> merge as we do the merge but still have the ability to rewind.
> I would
On Tue, Aug 18, 2009 at 5:57 PM, Tom Lane wrote:
> Hmmm ... actually, after looking at the code, I notice that we only
> consider adding a Materialize node to buffer an inner input that is a
> Sort node. The idea was suggested by Greg Stark, if memory serves.
> I wonder now if it'd be worthwhile t
I wrote:
> Matthew Wakeling writes:
>> Very clever. Yes, that is what is happening. I'm surprised that the system
>> doesn't buffer the inner side to avoid having to rescan each time, but
>> then I guess you would have problems if the buffer grew larger than
>> memory.
> Well, it does consider
Matthew Wakeling writes:
> Very clever. Yes, that is what is happening. I'm surprised that the system
> doesn't buffer the inner side to avoid having to rescan each time, but
> then I guess you would have problems if the buffer grew larger than
> memory.
Well, it does consider adding a Materia
On Tue, 18 Aug 2009, Tom Lane wrote:
Matthew Wakeling writes:
I'm seeing some interesting behaviour. I'm executing a query where I
perform a merge join between two copies of the same table, completely
symmetrically, and the two sides of the merge are sourced differently.
This is not as surpri
Matthew Wakeling writes:
> I'm seeing some interesting behaviour. I'm executing a query where I
> perform a merge join between two copies of the same table, completely
> symmetrically, and the two sides of the merge are sourced differently.
This is not as surprising as you think. A mergejoin i
I'm seeing some interesting behaviour. I'm executing a query where I
perform a merge join between two copies of the same table, completely
symmetrically, and the two sides of the merge are sourced differently.
SELECT COUNT(*)
FROM
(SELECT DISTINCT
l1.objectid,
l1.id AS id1
12 matches
Mail list logo
