Re: [HACKERS] GIT patch

2007-08-02 Thread Heikki Linnakangas
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 wo

Re: [HACKERS] GIT patch

2007-08-02 Thread Alexey Klyukin
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 > > poi

Re: [HACKERS] .NET driver

2007-08-02 Thread Hannu Krosing
Ü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 comparat

Re: [HACKERS] .NET driver

2007-08-02 Thread Merlin Moncure
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 .N

Re: [HACKERS] .NET driver

2007-08-02 Thread Andrei Kovalevski
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

Re: [HACKERS] .NET driver

2007-08-02 Thread Robert Treat
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 stat

Re: [HACKERS] clog_buffers to 64 in 8.3?

2007-08-02 Thread Tom Lane
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 o

[HACKERS] clog_buffers to 64 in 8.3?

2007-08-02 Thread Josh Berkus
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 Numbe

Re: [HACKERS] clog_buffers to 64 in 8.3?

2007-08-02 Thread Tom Lane
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 realist

Re: [HACKERS] clog_buffers to 64 in 8.3?

2007-08-02 Thread Josh Berkus
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

Re: [HACKERS] GIT patch

2007-08-02 Thread Bruce Momjian
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 win

Re: [HACKERS] clog_buffers to 64 in 8.3?

2007-08-02 Thread Greg Smith
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 downsides

Re: [HACKERS] GIT patch

2007-08-02 Thread Heikki Linnakangas
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

Re: [HACKERS] GIT patch

2007-08-02 Thread Tom Lane
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

Re: [HACKERS] .NET driver

2007-08-02 Thread Brar Piening
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 Francisco

Re: [HACKERS] .NET driver

2007-08-02 Thread Brar Piening
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 PostgreSQL-i

Re: [HACKERS] .NET driver

2007-08-02 Thread Andrew Dunstan
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 s

[HACKERS] Tracking a snapshot on PITR slaves

2007-08-02 Thread Florian G. Pflug
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 ne