Re: Very slow queries w/ NOT IN preparation (seems like a bug, test case)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Very slow queries w/ NOT IN preparation (seems like a bug, test case)
Date: 2008-11-11 20:20:56
Message-ID: 11792.1226434856@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Richard Huxton <dev(at)archonet(dot)com> writes:
> If you connect via psql and then (as root, in another terminal) do:
> ps auxw | grep postgres
> you should see the backend that corresponds to your psql connection.
> strace -p <pid>
> should then show system calls as they are executed (assuming you have it
> installed). Execute the explain, and see what is output.

> Mine flies past, but is composed almost entirely of "gettimeofday" calls
> (10,000 of them) apart from at the very end where we get some write and
> send/recv calls (to print the explain results). I've heard of some
> people having slow "gettimeofday" calls, but not on linux. On the other
> hand, that seems to be the main difference between strace output with
> "not in" compared to "in".

AFAICT Sergey is complaining about the speed of EXPLAIN, *not* EXPLAIN
ANALYZE. There'd only be a lot of gettimeofday calls in an EXPLAIN
ANALYZE test.

The whole thing doesn't make a lot of sense to me either. All the
slowdown explanations I can think of would apply as much or more to the
IN case...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vaclav TVRDIK 2008-11-11 20:38:42 Re: Timestamp precission question
Previous Message Tom Lane 2008-11-11 20:17:39 Re: Very slow queries w/ NOT IN preparation (seems like a bug, test case)

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2008-11-11 20:37:42 Re: failed test float8 on mingw
Previous Message Tom Lane 2008-11-11 20:17:39 Re: Very slow queries w/ NOT IN preparation (seems like a bug, test case)