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
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
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
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:
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
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
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
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
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 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 is some of the data for these
11 matches
Mail list logo
