Hello Tim,
>Re-implementation of a solution is often a hard case to sell, but it
>might be the only way to get the performance you want. The big positive
>to a re-implementation is that you usually get a better solution because
>you are implementing with more knowledge and experience about the
padusuma writes:
> Hello Tim,
>
>>How are you gathering metrics to determine if performance has improved
>>or not?
> I am measuring the response times through timer for the execution of SQL
> statements through psqlODBC driver. The response times for INSERT INTO
> temp-table statements have not
Hello Tim,
>How are you gathering metrics to determine if performance has improved
>or not?
I am measuring the response times through timer for the execution of SQL
statements through psqlODBC driver. The response times for INSERT INTO
temp-table statements have not changed with the parameters I
padusuma writes:
> Hello Tim,
>
> I have tried the suggestions provided to the best of my knowledge, but I did
> not see any improvement in the INSERT performance for temporary tables. The
> Linux host on which PostgreSQL database is installed has 32 GB RAM.
> Following are current settings I h
Hello Tim,
I have tried the suggestions provided to the best of my knowledge, but I did
not see any improvement in the INSERT performance for temporary tables. The
Linux host on which PostgreSQL database is installed has 32 GB RAM.
Following are current settings I have in postgresql.conf file:
sha
Hello Tim,
>> I have increased the value for /temp_buffers/ server parameter from the
>> default 8 MB to 128 MB. However, this change did not affect the INSERT
>> time
>> for temporary tables.
>It isn't clear why you create vectors of strings rather than just select
>into or something similar
padusuma writes:
>>We are inserting large numbers (millions) of rows into a postgres
>>database from a Javascript application and found using the COPY command
>>was much, much faster than doing regular inserts (even with multi-insert
>>commit). If you can do this using the driver you are using,
Hello Sergei,
>> The data to be inserted into temporary tables is obtained from one or
>> more
>> queries run earlier and the data is available as a vector of strings.
>You can not use "insert into temp_table select /*anything you wish*/"
statement?
>Or even insert .. select ... returning if you
Hello
> The data to be inserted into temporary tables is obtained from one or more
> queries run earlier and the data is available as a vector of strings.
You can not use "insert into temp_table select /*anything you wish*/" statement?
Or even insert .. select ... returning if you need receive dat
>We are inserting large numbers (millions) of rows into a postgres
>database from a Javascript application and found using the COPY command
>was much, much faster than doing regular inserts (even with multi-insert
>commit). If you can do this using the driver you are using, that will
>give you the
padusuma writes:
> I am working on adding support for PostgreSQL database for our application.
> In a lot of our use-cases, data is inserted into temporary tables using
> INSERT INTO statements with bind parameters, and subsequently queries are
> run by joining to these temp tables. Following i
11 matches
Mail list logo
