Thanks for the suggestions, Tom. But I'm still stumped.
On Apr 9, 2007, at 7:13 PM, Tom Lane wrote:
Drew Wilson <[EMAIL PROTECTED]> writes:
Here's the query plan for a SELECT statement that returns 1,207,161
rows in 6 seconds.
...
And here's the query plan for the UPDATE query that seems to ne
Drew Wilson <[EMAIL PROTECTED]> writes:
> Here's the query plan for a SELECT statement that returns 1,207,161
> rows in 6 seconds.
> ...
> And here's the query plan for the UPDATE query that seems to never
> complete. (Execution time > 30 minutes.)
Well, the subplan is certainly the same as be
My apologies. That function call was some test code to verify that my
subselect was only being called once.
Let me try again, please.
Here's the query plan for a SELECT statement that returns 1,207,161
rows in 6 seconds.
MatchBox=# explain select count(translation_pair_id) from
translation
Hi Jan,
Adding this Index slowed down things by a factor of 4.
Also, the performance is so horrible (example bellow) that i am
certain i am doing something wrong.
Does the following explain gives any ideas ?
Thanks
=# EXPLAIN ANALYZE select * from word_association where (word1 ='the'
or word2
Spiegelberg, Greg wrote:
We have a query which generates a small set of rows (~1,000) which are
to be used in a DELETE on the same table. The problem we have is that
we need to join on 5 different columns and it takes far too long.
You may have encountered the same problem I did: You *must*
Drew Wilson <[EMAIL PROTECTED]> writes:
> I have 2 tables (A,B) joined in a many-to-many relationship via a
> join table ("membership"), where updating table A based on table B
> takes a very long time.
> ...
> -> Function Scan on a (cost=0.00..12.50 rows=1000 width=4)
I think you've lef
On 4/9/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I have an odd performance issue on 8.2 that I'd thought I'd document
> here. I have a workaround, but I'm if there is something that I'm not
> seeing.
It's hard to comment on this without seeing the fu
On 4/9/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I have an odd performance issue on 8.2 that I'd thought I'd document
> here. I have a workaround, but I'm if there is something that I'm not
> seeing.
It's hard to comment on this without seeing the fu
On 4/9/07, Drew Wilson <[EMAIL PROTECTED]> wrote:
I have 2 tables (A,B) joined in a many-to-many relationship via a
join table ("membership"), where updating table A based on table B
takes a very long time.
Tables A and B have oid primary keys (a_id and b_id respectively).
The join table, "membe
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I have an odd performance issue on 8.2 that I'd thought I'd document
> here. I have a workaround, but I'm if there is something that I'm not
> seeing.
It's hard to comment on this without seeing the full details of the view
and tables. I'm wondering
On Mon, 2007-04-09 at 16:05 -0400, Carlos Moreno wrote:
> And by the subject, I mean: please provide a "factual" answer, as opposed
> to the more or less obvious answer which would be "no one in their sane
> mind would even consider doing such thing" :-)
>
> 1) Would it be possible to entirely d
"Spiegelberg, Greg" <[EMAIL PROTECTED]> writes:
> We have a query which generates a small set of rows (~1,000) which are
> to be used in a DELETE on the same table. The problem we have is that
> we need to join on 5 different columns and it takes far too long. I
> have a solution but I'm not sure
I have 2 tables (A,B) joined in a many-to-many relationship via a
join table ("membership"), where updating table A based on table B
takes a very long time.
Tables A and B have oid primary keys (a_id and b_id respectively).
The join table, "membership", has its own oid primary key
(membersh
On 4/9/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
On 4/9/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 4/6/07, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> > On Fri, Apr 06, 2007 at 04:38:33PM -0400, Alex Deucher wrote:
> > > One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
>
And by the subject, I mean: please provide a "factual" answer, as opposed
to the more or less obvious answer which would be "no one in their sane
mind would even consider doing such thing" :-)
1) Would it be possible to entirely disable WAL? (something like setting a
symlink so that pg_xlog p
We have a query which generates a small set of rows (~1,000) which are
to be used in a DELETE on the same table. The problem we have is that
we need to join on 5 different columns and it takes far too long. I
have a solution but I'm not sure it's the right one. Instead of joining
on 5 columns in
On 4/9/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
On 4/6/07, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 06, 2007 at 04:38:33PM -0400, Alex Deucher wrote:
> > One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
> > onto 8.2, both have locale set to C. 8.2 seems to pre
I have an odd performance issue on 8.2 that I'd thought I'd document
here. I have a workaround, but I'm if there is something that I'm not
seeing.
ok, for starters:
I have a large table that is basically organized like this:
create table big
(
key1 int,
key2 int,
ts timestamp
[other fields]
On 4/6/07, Michael Fuhr <[EMAIL PROTECTED]> wrote:
On Fri, Apr 06, 2007 at 04:38:33PM -0400, Alex Deucher wrote:
> One more anomaly between 7.4 and 8.2. DB dumped from 7.4 and loaded
> onto 8.2, both have locale set to C. 8.2 seems to prefer Seq Scans
> for the first query while the ordering in
"s d" <[EMAIL PROTECTED]> writes:
> 1. i can undestand where the cost=11.53 came from but where did the
> 1192.09 come form? The values are in milli right ?
No, the unit of estimated cost is 1 disk page fetch. See
http://www.postgresql.org/docs/8.2/static/using-explain.html
Hi,
I am trying to figure out how to debug a performance problem / use psql explain.
The table in question is:
# \d word_association;
Table "public.word_association"
Column | Type | Modifiers
++
word1 | character
21 matches
Mail list logo
