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 intere
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
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
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.
>
> Sh
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.
In
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,
prim
[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 raise
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 partiti
> 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
> mag
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
> 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 i
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
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
13 matches
Mail list logo
