Any response?
On 10/27/06, soni de <[EMAIL PROTECTED]> wrote:
Hello,
My Server is crashed in PQfinish. Below is the core file details:
=>[1] DLRemHead(0x2b7780, 0xfb6bc008, 0x319670, 0xfb6bc008, 0x21c40, 0x3106f8), at 0xfded10e4 [2] DLFreeList(0x2b7780, 0x0, 0x417b48, 0xfdec5aa4, 0x21c18, 0
Leif Mortenson <[EMAIL PROTECTED]> writes:
> Having a column containing large numbers of null or 0 values seems fairly
> common.
You would likely be better off to use NULL as a no-value placeholder,
instead of an arbitrarily chosen regular value (which the planner cannot
be certain does not match
On Oct 31, 2006, at 13:04 , Leif Mortenson wrote:
Hello,
I have been having a problem with the following query ignoring an
index
on the foos.bar column.
SELECT c.id
FROM foos c, bars r
WHERE r.id != 0
AND r.modified_time > '2006-10-20 10:00:00.000'
AND r.modified_time <= '2006-10-30 15:20:0
Hello,
I have been having a problem with the following query ignoring an index
on the foos.bar column.
SELECT c.id
FROM foos c, bars r
WHERE r.id != 0
AND r.modified_time > '2006-10-20 10:00:00.000'
AND r.modified_time <= '2006-10-30 15:20:00.000'
AND c.bar = r.id
The bars table contains 597 rows
On Mon, 2006-10-30 at 22:58 +0100, Andreas Kostyrka wrote:
> Am Montag, den 30.10.2006, 08:18 + schrieb Simon Riggs:
> > On Sun, 2006-10-29 at 00:28 +0200, Andreas Kostyrka wrote:
> >
> > > Any ideas how to make the optimizer handle partitioned tables more
> > > sensible?
> >
> > Yes, those
Am Montag, den 30.10.2006, 08:18 + schrieb Simon Riggs:
> On Sun, 2006-10-29 at 00:28 +0200, Andreas Kostyrka wrote:
>
> > Any ideas how to make the optimizer handle partitioned tables more
> > sensible?
>
> Yes, those are known inefficiencies in the current implementation which
> we expect
>
> Yes, this issue comes up often - I wonder if the Woodcrest Xeons
resolved
> this? Have these problems been experienced on both Linux and Windows
(we
> are
> running Windows 2003 x64)
>
> Carlo
>
IIRC Woodcrest doesn't have HT, just dual core with shared cache.
- Bucky
-
Luke Lonergan wrote:
Stefan,
On 10/30/06 8:57 AM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
We've found that there is an ultimate bottleneck at about 12-14MB/s despite
having sequential write to disk speeds of 100s of MB/s. I forget what the
latest bottleneck was.
I have personally m
Stefan,
On 10/30/06 8:57 AM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
>> We've found that there is an ultimate bottleneck at about 12-14MB/s despite
>> having sequential write to disk speeds of 100s of MB/s. I forget what the
>> latest bottleneck was.
>
> I have personally managed to l
Luke Lonergan wrote:
Greg,
On 10/30/06 7:09 AM, "Spiegelberg, Greg" <[EMAIL PROTECTED]> wrote:
I broke that file into 2 files each of 550K rows and performed 2
simultaneous COPY's after dropping the table, recreating, issuing a sync
on the system to be sure, &c and nearly every time both COPY'
On Mon, Oct 30, 2006 at 03:26:09PM +0100, Mattias Kregert wrote:
> On the left side it is text, and on the right side it is varchar(10).
> Casting left side to varchar(10) does not help, in fact it makes things
> even worse: The cast to ::text vanishes in a puff of logic, but the plan
> gets bigg
From: "Tom Lane" <[EMAIL PROTECTED]>
Mattias Kregert <[EMAIL PROTECTED]> writes:
Why does it come up with this strange plan?
Because 8.1 can't reorder outer joins. To devise the plan you want,
the planner has to be able to prove that it's OK to perform the IN join
before the LEFT join, someth
Greg,
On 10/30/06 7:09 AM, "Spiegelberg, Greg" <[EMAIL PROTECTED]> wrote:
> I broke that file into 2 files each of 550K rows and performed 2
> simultaneous COPY's after dropping the table, recreating, issuing a sync
> on the system to be sure, &c and nearly every time both COPY's finish in
> 12 s
Mattias Kregert <[EMAIL PROTECTED]> writes:
> Why does it come up with this strange plan?
Because 8.1 can't reorder outer joins. To devise the plan you want,
the planner has to be able to prove that it's OK to perform the IN join
before the LEFT join, something that isn't always the case. 8.2 ca
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
On Mon, Oct 30, 2006 at 01:05:07PM +0200, Mattias Kregert wrote:
-> Hash Left Join (cost=59.66..206763.11 rows=1215336
width=27) (actual time=4.959..3228.550 rows=1216434 loops=1)
Hash Cond: (("outer".prislista = ("inner"
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Luke Lonergan
> Sent: Saturday, October 28, 2006 12:07 AM
> To: Worky Workerson; Merlin Moncure
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Best COPY Performance
>
> Worky,
>
>
On Mon, Oct 30, 2006 at 01:05:07PM +0200, Mattias Kregert wrote:
> -> Hash Left Join (cost=59.66..206763.11 rows=1215336 width=27)
> (actual time=4.959..3228.550 rows=1216434 loops=1)
>Hash Cond: (("outer".prislista = ("inner".listid)::text) AND
> ("outer".tjanst = ("in
Look at this insane plan:
lucas=# explain analyse select huvudklass,sum(summa) from kor_tjanster left
outer join prislist on prislista=listid and tjanst=tjanstid where kor_id in
(select id from kor where lista=10484) group by 1;
QU
On Sun, 2006-10-29 at 00:28 +0200, Andreas Kostyrka wrote:
> Any ideas how to make the optimizer handle partitioned tables more
> sensible?
Yes, those are known inefficiencies in the current implementation which
we expect to address for 8.3.
--
Simon Riggs
EnterpriseDB http:
19 matches
Mail list logo
