Excerpts from David Kerr's message of lun ago 23 18:47:02 -0400 2010:
> unlink("base/pgsql_tmp/pgsql_tmp28335.12593") = 0
> unlink("base/pgsql_tmp/pgsql_tmp28335.6041") = 0
> unlink("base/pgsql_tmp/pgsql_tmp28335.3030") = 0
> unlink("base/pgsql_tmp/pgsql_tmp28335.14737") = 0
>
> which isn't the f
On Mon, Aug 23, 2010 at 06:23:25PM -0400, Alvaro Herrera wrote:
- Excerpts from David Kerr's message of lun ago 23 18:15:56 -0400 2010:
- > Howdy all,
- >
- > We're doing some performance testing, and when we scaled it our app up to
about 250 concurrent users
- > we started seeing a bunch of proc
Excerpts from David Kerr's message of lun ago 23 18:15:56 -0400 2010:
> Howdy all,
>
> We're doing some performance testing, and when we scaled it our app up to
> about 250 concurrent users
> we started seeing a bunch of processes sititng in "PARSE WAITING" state.
>
> Can anyone give me insite o
probably waiting on the xlog directory that's filled up...
->->blamo
move along, nothing to see here =)
Dave
On Mon, Aug 23, 2010 at 03:15:56PM -0700, David Kerr wrote:
- Howdy all,
-
- We're doing some performance testing, and when we scaled it our app up to
about 250 concurrent users
- w
Howdy all,
We're doing some performance testing, and when we scaled it our app up to about
250 concurrent users
we started seeing a bunch of processes sititng in "PARSE WAITING" state.
Can anyone give me insite on what this means? what's the parse waiting for?
Thanks
Dave
--
Sent via pgsql-p
Trigger is the way to go.
André.
Date: Mon, 23 Aug 2010 11:42:21 -0700
Subject: [PERFORM] Triggers or code?
From: dm.a...@gmail.com
To: pgsql-performance@postgresql.org
Hello There,
I have a table x and a history table x_hist, whats the best way to update the
history table.
should i need to
Hello There,
I have a table x and a history table x_hist, whats the best way to update
the history table.
should i need to use triggers or embed a code in my script to update the
history table?
what is the performance impact of a trigger versus embedding the code in the
script?
thanks for your
On Mon, Aug 23, 2010 at 7:19 AM, Jann Röder wrote:
> Thanks for your help,
> here is the information you requested:
>
> Table information: A = Papers, B = PaperReferences
>
> wos-db=> \d Papers
> Table "public.papers"
> Column | Type | Modifiers
> -
>I may be a little bit over-sensitive on the topic, because I've seen
>so many people who consider it "wrong" to use natural keys on any
>table *ever*. About one out of every four or five programmers who
>gets hired here feels compelled to argue that we should add
>surrogate keys to all our tables
Alvaro Herrera writes:
> Hmm, I'm placing bets on the bpchar weirdness. I'd try getting rid of
> that and using plain varchar for all the columns.
That's certainly what's inhibiting it from considering an indexscan
on the larger table. I'm not as convinced as the OP that a nestloop
indexscan is
Grzegorz Jaœkiewicz wrote:
> So, don't narrow down to one solution because it worked for you.
> Keep an open book.
What I was trying to do was advise on what would most directly fix
the problem. Adding surrogate keys goes way beyond adding the
columns and using them as keys, as I'm sure you're
Oh, and I second using same types in joins especially, very much so :)
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
I am not a fan of 'do this - this is best' response to queries like that.
Rather: this is what you should try, and choose whichever one suits you better.
So, rather than 'natural keys ftw', I am giving him another option to
choose from.
You see, in my world, I was able to improve some large dbs pe
Excerpts from Jann Röder's message of lun ago 23 00:23:38 -0400 2010:
> "Hash Join (cost=516.66..17710110.47 rows=8358225 width=16)"
> " Hash Cond: ((b.itemid)::bpchar = a.itemid)"
> " -> Seq Scan on b (cost=0.00..15110856.68 rows=670707968 width=16)"
> " -> Hash (cost=504.12..504.12 rows=
Grzegorz Jaœkiewicz wrote:
> True, but as far as joining is concerned, joining on single column
> fixed length fields is always going to be a win. Hence why
> surrogate keys make sens in this particular example, or the guy
> here should at least test it to see, rather than believe in one or
> the
On Mon, Aug 23, 2010 at 2:47 PM, Kevin Grittner
wrote:
> Grzegorz Jaœkiewicz wrote:
>
>> joining on varchars is always going to be very expensive. Longer
>> the value is, more expensive it will be. Consider going for
>> surrogate keys.
>
> Surrogate keys come with their own set of costs and introd
Grzegorz Jaœkiewicz wrote:
> joining on varchars is always going to be very expensive. Longer
> the value is, more expensive it will be. Consider going for
> surrogate keys.
Surrogate keys come with their own set of costs and introduce quite
a few problems of their own. I don't want to start a
Jann Röder wrote:
> Table "public.papers"
> Column | Type | Modifiers
> --+-+---
> itemid | character(15) | not null
> wos-db=> \d PaperReferences
> Table "public.pap
joining on varchars is always going to be very expensive. Longer the
value is, more expensive it will be. Consider going for surrogate
keys.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Thanks for your help,
here is the information you requested:
Table information: A = Papers, B = PaperReferences
wos-db=> \d Papers
Table "public.papers"
Column | Type | Modifiers
--+-+---
itemid
I forgot to paste link:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Jann Röder wrote:
Am 23.08.10 12:18, schrieb Scott Marlowe:
>> What happens if you try
>>
>> set enable_seqscan=off;
>> (your query here)
>>
> Tried that already. The query plan is exactly the same.
Exactly? Not even the cost shown for the seq scan changed?
You are almost certainly omitting
Am 23.08.10 12:18, schrieb Scott Marlowe:
> On Mon, Aug 23, 2010 at 4:15 AM, Jann Röder wrote:
>> Am 23.08.10 07:52, schrieb Scott Marlowe:
>>> Also are a.indexid and b.indexid the same type?
>>>
>>
>> You mean ItemID? Fields of the same name are of the same type - so yes.
>> According to the docu
On Mon, Aug 23, 2010 at 4:15 AM, Jann Röder wrote:
> Am 23.08.10 07:52, schrieb Scott Marlowe:
>> Also are a.indexid and b.indexid the same type?
>>
>
> You mean ItemID? Fields of the same name are of the same type - so yes.
> According to the documentation pgsql adds indexes for primary keys
> au
Am 23.08.10 07:52, schrieb Scott Marlowe:
> Also are a.indexid and b.indexid the same type?
>
You mean ItemID? Fields of the same name are of the same type - so yes.
According to the documentation pgsql adds indexes for primary keys
automatically so (b.itemID, b.indexNumber) is indexed. Or do you
25 matches
Mail list logo
