Hi all!
2007/7/18, Thomas Finneid [EMAIL PROTECTED]:
Hi I have tested your COPY patch (actually I tested
postgresql-jdbc-8.2-505-copy-20070716.jdbc3.jar) and it is really fast,
actually just as fast as serverside COPY (boths tests was performed on
local machine).
Happy to hear there's
Kalle Hallivuori wrote:
Hi.
2007/7/8, Thomas Finneid [EMAIL PROTECTED]:
Kalle Hallivuori wrote:
COPY is plentitudes faster than INSERT:
http://www.postgresql.org/docs/8.1/interactive/sql-copy.html
If you can't just push the data straight into the final table with
COPY, push it
Kalle Hallivuori wrote:
COPY is plentitudes faster than INSERT:
http://www.postgresql.org/docs/8.1/interactive/sql-copy.html
If you can't just push the data straight into the final table with
COPY, push it into a temporary table that you go through with the
database procedure.
Shameless
Hi.
2007/7/8, Thomas Finneid [EMAIL PROTECTED]:
Kalle Hallivuori wrote:
COPY is plentitudes faster than INSERT:
http://www.postgresql.org/docs/8.1/interactive/sql-copy.html
If you can't just push the data straight into the final table with
COPY, push it into a temporary table that
Hi Thomas all,
2007/7/6, Thomas Finneid [EMAIL PROTECTED]:
Heikki Linnakangas wrote:
ISTM that a properly normalized schema would look something like this:
[example of tables per attr referencing main table containing only primary key]
I agree that this is a way it could be done.
Hi
I have the following scenario for a database that I need to design, and
would like some hints on what to improve or do differently to achieve the
desired performance goal, disregarding hardware and postgres tuning.
The premise is an attribute database that stores about 100 different
attribute
I would strongly suggest that you use a proper relational schema,
instead of storing everything in two tables. I don't know your
application, but a schema like that is called an Entity-Attribute-Value
(though your entity seems to be just posx and posy) and it should raise
a big red flag in the
I would strongly suggest that you use a proper relational schema,
instead of storing everything in two tables. I don't know your
application, but a schema like that is called an Entity-Attribute-Value
(though your entity seems to be just posx and posy) and it should raise
a big red flag in
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I would strongly suggest that you use a proper relational schema,
instead of storing everything in two tables. I don't know your
application, but a schema like that is called an Entity-Attribute-Value
(though your entity seems to be just
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I don't know much about this EAV stuff. Except to say that my company is
in
a situation with a lot of adds and bulk deletes and I wish the tables were
designed with partitioning in mind. That is if you know how much, order of
magnitude,
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I don't know much about this EAV stuff. Except to say that my company is
in
a situation with a lot of adds and bulk deletes and I wish the tables
were
designed with partitioning in
[EMAIL PROTECTED] wrote:
I would strongly suggest that you use a proper relational schema,
instead of storing everything in two tables. I don't know your
application, but a schema like that is called an Entity-Attribute-Value
(though your entity seems to be just posx and posy) and it should
Heikki Linnakangas wrote:
ISTM that a properly normalized schema would look something like this:
create table position (
posX int not null,
posY int not null,
primary key (posX, posY)
);
create table colour (
posX int not null,
posY int not null,
colour varchar(50) not null,
13 matches
Mail list logo
