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
"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
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
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/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
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
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
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
>
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
"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
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
"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 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
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
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
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*
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
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
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
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
21 matches
Mail list logo
