On Sun, Aug 05, 2007 at 11:20:18AM -0400, Tom Lane wrote:
> "Dirk Tilger" <[EMAIL PROTECTED]> writes:
> > Operating system: Linux with Intel compiler on ia64
>
> > I have been compiling postgresql 8.0, 8.1 and 8.2.4 with the Intel compiler
> > in the past successfully. This time something went w
The following bug has been logged online:
Bug reference: 3518
Logged by: Tomasz Kawczynski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux Gentoo
Description:ERROR: IN types character varying and integer cannot be
matched
Details:
The following bug has been logged online:
Bug reference: 3519
Logged by: Mouhamadou DIA
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Solaris 10 and Linux Redhat 4
Description:Postgres takes the wrong query plan resulting in
performance
Dirk Tilger <[EMAIL PROTECTED]> writes:
> FYI: we also apply the attached patch to postgre, so that the
> 'configure' script would not add the -mp1, when -mp was already
> specified. From the manual:
There is absolutely no chance that we will accept this patch, as it is
known to break Postgres.
"Tomasz Kawczynski" <[EMAIL PROTECTED]> writes:
> SELECT * FROM s_skladnik WHERE kod IN (902,902)
> ERROR: IN types character varying and integer cannot be matched
> whitch is ok (ive read about this restriction in 8.2.x)
> but why after
> SELECT * FROM s_skladnik WHERE kod IN (902)
> or
> SELE
Mouhamadou DIA wrote:
> I've migrated to Postgres 8.2.4 and run the same query. It takes now 20
> seconds which is still not acceptable.
To help you with that, we'd need to see the EXPLAIN ANALYZE output of
the query, and the CREATE TABLE statements of the tables involved in the
query and their in
Mouhamadou Dia wrote:
> I'm sending in attachment the output of the explain analyze command and the
> create table statements of tables involved in the query.
Wait, you said that the query takes 20 seconds on 8.2, but the explain
analyze output says that it actually took 50 seconds. Is this the o
Hmm. I don't see anything terribly wrong in the planner's estimates. The
only estimate that's off is the # of rows in pror_org matching the qual
orgt_cd = 'CHAIN', 27 estimated vs 1 actual. You could try increasing
the statistics target for that column to get that estimate right. That
might tip the
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> So, it looks like the app polls for async notifies every second. Hopefully
> you can glean some insight from that.
My guess is that some condition causes that to stop happening.
One way to monitor this from outside is to use strace to watch the app.
Ac
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Have you played with enable_seqscan=off or enable_hashjoin=off? That's
> not a good long term solution, but it would be interesting to see what
> happens.
I think this is a case where Postgres just doesn't know it can re-order near
an outer join
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> Here's my theory (and feel free to tell me that I'm full of it)...somehow, a
> lot of notifies happened at once, or in a very short period of time, to the
> point where the app was still processing notifies when the timer clicked off
> another second. Th
Gregory Stark <[EMAIL PROTECTED]> writes:
> The structure of your query is a whole series of left outer joins, the result
> of which is then (inner) joined with one more table. The outer joins return a
> whole lot of records but the inner join is only going to match a few of them.
Hmmm ... actuall
12 matches
Mail list logo
