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
12 matches
Mail list logo
