I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET. As
stated on NPGSQL page, it doesn't seem to provide seamless integration and
performance with .NET. Instead when I used ODBC, the performance was
comparatively better. What's the reason? When can we expect .NET driver that
Alvaro Herrera wrote:
Hmm, do say, doesn't it seem like the lack of feedback and the failed
bitmap patch played against final development of this patch?
Yes :(. That's a one reason why I tried to help with the review of that
patch.
At this
point I feel like the patch still needs some work
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Hmm, do say, doesn't it seem like the lack of feedback and the failed
bitmap patch played against final development of this patch?
Yes :(. That's a one reason why I tried to help with the review of that
patch.
At this
point I feel
Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:
I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and performance with .NET. Instead when I used ODBC, the
performance was
On 8/2/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:
I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and performance with .NET.
Merlin Moncure wrote:
On 8/2/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:
I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and
On Thursday 02 August 2007 08:57, Andrei Kovalevski wrote:
Merlin Moncure wrote:
On 8/2/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:
I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL
Josh Berkus [EMAIL PROTECTED] writes:
Through the User Concurrency Thread on -performance [1], Tom and
Jignesh found that our proximate bottleneck on SMP multi-user scaling
is clog_buffers.
I don't actually think that what Jignesh is testing is a particularly
realistic scenario, and so I
All,
Through the User Concurrency Thread on -performance [1], Tom and Jignesh found
that our proximate bottleneck on SMP multi-user scaling is clog_buffers.
Increasing clog_buffers to 64 improved this scaling by 30% per Jignesh:
===
8.3+ HOT = did not defer more from 8.2
Josh Berkus [EMAIL PROTECTED] writes:
Tom,
I don't actually think that what Jignesh is testing is a particularly
realistic scenario, and so I object to making performance decisions on
the strength of that one measurement.
What do you mean by not realistic? What would be a realistic
Tom,
I don't actually think that what Jignesh is testing is a particularly
realistic scenario, and so I object to making performance decisions on
the strength of that one measurement.
What do you mean by not realistic? What would be a realistic scenario?
--
Josh Berkus
PostgreSQL @ Sun
San
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
I've started reading the GIT patch to see if I can help with the review.
As the patch stands, I tried to keep it as non-invasive as possible,
with minimum changes to existing APIs. That's because in the winter we
On Thu, 2 Aug 2007, Tom Lane wrote:
I find it entirely likely that simply changing the [NUM_CLOG_BUFFERS]
constant would be a net loss on many workloads.
Would it be reasonable to consider changing it to a compile-time option
before the 8.3 beta? From how you describe the potential
Alexey Klyukin wrote:
Well, then should we return to the review of your 'bitmapscan changes'
patch ? I've posted a version which applies (or applied to the cvs head
at the time of post) cleanly there:
http://archives.postgresql.org/pgsql-patches/2007-06/msg00204.php
Yes, that's probably a
Heikki Linnakangas [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
At this
point I feel like the patch still needs some work and reshuffling before
it is in an acceptable state. The fact that there are some API changes
for which the patch needs to be adjusted makes me feel like we should
Andrei Kovalevski schrieb:
I have an experience with writing ODBC driver for PostgreSQL
(https://projects.commandprompt.com/public/odbcng/). I would be happy
to help community to improve .NET data provider.
Please join the Npgsql Project at http://pgfoundry.org/projects/npgsql
Robert Treat schrieb:
That would be nice. Of course none of this seems relevant to hackers, so I'd
Your'e right - of course.
But sometimes I wish 'hackers' would care a little more about their
interfaces as the best backend can't be good without good interfaces and
some of the
Brar Piening wrote:
Robert Treat schrieb:
That would be nice. Of course none of this seems relevant to hackers,
so I'd
Your'e right - of course.
But sometimes I wish 'hackers' would care a little more about their
interfaces as the best backend can't be good without good interfaces
and
Hi
Since my attempts to find a simple solution for the read-only query
locking problems (Once that doesn't need full wal logging of lock
requests) haven't been successfully yet, I've decided to turn to the
problems of tracking a snapshot on the slaves for now. (Because first
such a snapshot is
19 matches
Mail list logo
