On Wed, 2004-07-21 at 06:04, Steinar H. Gunderson wrote:
> On Tue, Jul 20, 2004 at 10:18:19PM -0400, Rod Taylor wrote:
> > I've taken a look and managed to cut out quite a bit of used time.
> > You'll need to confirm it's the same results though (I didn't -- it is
> > the same number of results (qu
On Tue, Jul 20, 2004 at 10:18:19PM -0400, Rod Taylor wrote:
> I've taken a look and managed to cut out quite a bit of used time.
> You'll need to confirm it's the same results though (I didn't -- it is
> the same number of results (query below)
It looks very much like the same results.
> Secondly
> I could of course post the updated query plan if anybody is interested; let
> me know. (The data is still available if anybody needs it as well, of
> course.)
I've taken a look and managed to cut out quite a bit of used time.
You'll need to confirm it's the same results though (I didn't -- it is
On Tue, Jul 20, 2004 at 10:06:08AM -0700, Josh Berkus wrote:
> Actually, quick question -- have you tried setting enable_mergjoin=false to
> see the plan the system comes up with? Is it in fact faster?
It is significantly faster -- 1200ms vs. 1900ms (on 7.4, at least). Some of
the merge joins ar
Steinar,
> I've tried some further tweaking, but I'm still unable to force it into
> doing a hash join -- any ideas how I can find out why it chooses a merge
> join?
Actually, quick question -- have you tried setting enable_mergjoin=false to
see the plan the system comes up with? Is it in fact
Steinar,
> I've tried some further tweaking, but I'm still unable to force it into
> doing a hash join -- any ideas how I can find out why it chooses a merge
> join?
I'm sorry, I can't really give your issue the attention it deserves. At this
point, I'd have to get a copy of your database, and
On Thu, Jul 15, 2004 at 02:08:54PM +0200, Steinar H. Gunderson wrote:
> sort_mem is already 16384, which I thought would be plenty -- I tried
> increasing it to 65536 which made exactly zero difference. :-)
I've tried some further tweaking, but I'm still unable to force it into doing
a hash join -
On Thu, Jul 15, 2004 at 11:11:33AM -0700, Josh Berkus wrote:
>> sort_mem is already 16384, which I thought would be plenty -- I tried
>> increasing it to 65536 which made exactly zero difference. :-)
> Well, then the next step is increasing the statistical sampling on the 3 join
> columns in that
Steinar,
> sort_mem is already 16384, which I thought would be plenty -- I tried
> increasing it to 65536 which made exactly zero difference. :-)
Well, then the next step is increasing the statistical sampling on the 3 join
columns in that table. Try setting statistics to 500 for each of the 3
On Thu, Jul 15, 2004 at 12:52:38AM -0400, Tom Lane wrote:
> No, it's not missing anything. The number being reported here is the
> number of rows pulled from the plan node --- but this plan node is on
> the inside of a merge join, and one of the properties of merge join is
> that it will do partia
Josh Berkus <[EMAIL PROTECTED]> writes:
>> - The "subquery scan o12" phase outputs 1186 rows, yet 83792 are sorted.
> Where
>> do the other ~82000 rows come from?
> I'm puzzled by the "83792" rows as well. I've a feeling that Explain
> Analyze is failing to output a step.
No, it's not missing a
Steinar,
> - The "subquery scan o12" phase outputs 1186 rows, yet 83792 are sorted.
Where
> do the other ~82000 rows come from? And why would it take ~100ms to sort
the
> rows at all? (In earlier tests, this was _one full second_ but somehow
that
> seems to have improved, yet without real
On Thu, Jul 08, 2004 at 12:19:13PM +0200, Steinar H. Gunderson wrote:
> I'm trying to find out why one of my queries is so slow -- I'm primarily
> using PostgreSQL 7.2 (Debian stable), but I don't really get much better
> performance with 7.4 (Debian unstable). My prototype table looks like this:
[Apologies if this reaches the list twice -- I sent a copy before
subscribing, but it seems to be stuck waiting for listmaster forever, so I
subscribed and sent it again.]
Hi,
I'm trying to find out why one of my queries is so slow -- I'm primarily
using PostgreSQL 7.2 (Debian stable), but I do
[Please CC me on all replies, I'm not subscribed to this list]
Hi,
I'm trying to find out why one of my queries is so slow -- I'm primarily
using PostgreSQL 7.2 (Debian stable), but I don't really get much better
performance with 7.4 (Debian unstable). My prototype table looks like this:
CREAT
15 matches
Mail list logo
