On Thu, Jan 21, 2010 at 9:27 PM, Allen Johnson wrote:
> What I noticed in the production query was that ~1000ms was spent on
> sorting alone. The hack query reduced that to ~400ms. I should also
> note that there was plenty of work_mem and that the sort was not
> hitting disk.
>
The "hack" form a
On Fri, Jan 22, 2010 at 2:02 PM, Greg Stark wrote:
> The question arises why Postgres can't automatically detect that this
> query is equivalent.
Hm, actually rereading your query it's not technically equivalent.
Since you weren't grouping on contact.id or contact_type.code if you
happened to hav
On Jan 21, 6:17 pm, mi...@radev.net ("Milen A. Radev") wrote:
>
> [...]
>
> For the test I changed all regional settings to "Polish (Poland)",
> restarted the machine, created a new cluster and a new database (using
> the commands from the last mail from Heikki).
>
> A side-note: tested exactly the
WildWezyr написа:
On Jan 21, 6:17 pm, mi...@radev.net ("Milen A. Radev") wrote:
[...]
For the test I changed all regional settings to "Polish (Poland)",
restarted the machine, created a new cluster and a new database (using
the commands from the last mail from Heikki).
A side-note: tested exac
Allen Johnson writes:
> Ok, I've generated a test database with:
> * 20,000 users
> * 250,000 contacts
> * 1,124,700 attachments
> The summary of the results is that the normal query takes about 32sec
> on my machine. The hack query takes about 13sec.
I poked at this for a bit. At least w
