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
On Mon, Jun 18, 2012 at 9:39 AM, Anish Kejariwal 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. Inserts and
updates
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
suffic
Glad to hear postgresql becomes better and better :)
2012/6/18 Tom Lane
> =?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= 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 nest
Tom Lane 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 the slow cases.
=?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= 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 are exactly the
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 O