Re: SELECT's take a long time compared to other DBMS

From: "Relaxin" <noname(at)spam(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: SELECT's take a long time compared to other DBMS
Date: 2003-09-05 04:59:01
Message-ID: bj9565$2n3l$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> Is there a reason you can't use cursors (explicitely, or via ODBC if it
> provides some glue on top of them) to keep the result set on the server?
>
> http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-declare.html
> http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-fetch.html

I can only use generally accepted forms of connectivity (ie. ODBC, ADO or
OLEDB).
This is what many of the people on the Windows side are going to need,
because most of us are going to be converting from an existing already
established system, such as Oracle, SQL Server or DB2, all of which have 1
or more of the 3 mentioned above.

> > The next one is the handling of BLOBS. PG handles them like no other
system
> > I have ever come across.
>
> Just FYI, you can use both the lo_*() functions, as well as simple
> bytea/text columns (which can be very large in PostgreSQL).
>
> -Neil

I know PG has a ODBC driver (that's all I've been using), but it or PG just
doesn't handle BLOBS the way people on the Windows side (don't know about
Unix) are use too.

There is this conversion to octet that must be performed on the data , I
don't understand why, but I guess there was a reason for it long ago, but it
seems that it can now be modified to just accept ANY byte you give it and
then store it without any manipulation of the data.
This will make Postgresql much more portable for the Windows developers...no
need for any special handling for a data type that all large RDBMS support.

Thanks

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Bjorn T Johansen 2003-09-05 06:08:07 Seq scan of table?
Previous Message Eirik Oeverby 2003-09-05 04:54:24 Re: SELECT's take a long time compared to other DBMS