Re: How to determine cause of performance problem?
От | Michael Stone |
---|---|
Тема | Re: How to determine cause of performance problem? |
Дата | |
Msg-id | 20050923110500.GX14918@mathom.us обсуждение исходный текст |
Ответ на | Re: How to determine cause of performance problem? (Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>) |
Ответы |
Re: How to determine cause of performance problem?
Re: How to determine cause of performance problem? |
Список | pgsql-performance |
On Fri, Sep 23, 2005 at 12:21:15PM +0200, Joost Kraaijeveld wrote: >On Fri, 2005-09-23 at 05:55 -0400, Michael Stone wrote: >> It's not clear what your object id generator does. If it's just a >> sequence, it's not clear that you need this program at all--just use a >> SELECT INTO and make the object id a SERIAL. >It generates a GUID (and no, I do not want to turn this in a discussion >about GUIDs). As in the Java code comment: it is not the generation of >the GUID that is the problem (that is, I can generate millions of them >per second.) I didn't say it was, did I? If you use a SELECT INTO instead of SELECTing each record and then reINSERTing it you avoid a round trip latency for each row. There's a reason I said "if it's just a sequence". >> If you do need to control the object id or do some other processing >> before putting the data into the new table, rewrite to use a COPY >> instead of an INSERT. >It is actually the shortest piece of code that gives me a poor >performance. The conversion problem is much, much larger and much much >more complicated. Ok, that's great, but you didn't respond to the suggestion of using COPY INTO instead of INSERT. >But I have no clue where to begin with determining the bottleneck (it >even may be a normal performance for all I know: I have no experience >with converting such (large) database). > >Any suggestions? Respond to the first suggestion? Mike Stone
В списке pgsql-performance по дате отправления: