Re: [PERFORM] Expected performance of querying 5k records from 4 million records?

2012-06-18 Thread Josh Berkus
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

Re: [PERFORM] Expected performance of querying 5k records from 4 million records?

2012-06-18 Thread Samuel Gendler
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

Re: [PERFORM] Expected performance of querying 5k records from 4 million records?

2012-06-18 Thread Anish Kejariwal
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

Re: [PERFORM] correlated exists with join is slow.

2012-06-18 Thread Віталій Тимчишин
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

Re: [PERFORM] correlated exists with join is slow.

2012-06-18 Thread Kevin Grittner
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.

Re: [PERFORM] correlated exists with join is slow.

2012-06-18 Thread 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 nested loop to make exists check. 9.2 will make this all better. These are exactly the

[PERFORM] correlated exists with join is slow.

2012-06-18 Thread Віталій Тимчишин
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