Hello.
Today I've found a query that I thought will be fast turned out to be slow.
The problem is correlated exists with join - it does not want to make
correlated nested loop to make exists check.
Even if I force it to use nested loop, it materialized join uncorrelated
and then filters it. It's
=?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= tiv...@gmail.com writes:
Today I've found a query that I thought will be fast turned out to be slow.
The problem is correlated exists with join - it does not want to make
correlated nested loop to make exists check.
9.2 will make this all better. These
Tom Lane t...@sss.pgh.pa.us wrote:
9.2 will make this all better. These are exactly the type of case
where you need the parameterized path stuff.
Yeah, with HEAD on my workstation all of these queries run in less
than 0.1 ms. On older versions, I'm seeing times like 100 ms to 150
ms for
Glad to hear postgresql becomes better and better :)
2012/6/18 Tom Lane t...@sss.pgh.pa.us
=?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= tiv...@gmail.com writes:
Today I've found a query that I thought will be fast turned out to be
slow.
The problem is correlated exists with join - it does not
Thanks for the help, Jeff and Josh. It looks reclustering the multi-column
index might solve things. For my particular query, because I'm getting a
range of records back, it makes sense that reclustering will benefit me if
I have a slow disk even if I had expected that the indices would be
On Mon, Jun 18, 2012 at 9:39 AM, Anish Kejariwal anish...@gmail.com wrote:
So, it looks like clustering the index appropriately fixes things! Also,
I'll recreate the index switching the order to (dataset_id, stat_id,data_id)
Just keep in mind that clustering is a one-time operation.
On 6/18/12 9:39 AM, Anish Kejariwal wrote:
Thanks for the help, Jeff and Josh. It looks reclustering the multi-column
index might solve things. For my particular query, because I'm getting a
range of records back, it makes sense that reclustering will benefit me if
I have a slow disk even if
