- 12 10月, 2000 12 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
(failed to say that it conflicts with AccessShareLock).
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
-
- 11 10月, 2000 8 次提交
-
-
由 Philip Warner 提交于
(will be used in a future pg_dump).
-
由 Michael Meskes 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
anyway, the rest being due to them not being kept in sync. Add configure test for lorder and use it (on Solaris) when found.
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
it previously. The patch included is against fairly current sources, but it may apply cleanly against 7.0.2 as well. On Fri, 6 Oct 2000, Vilson farias wrote: > I found a irregular behavior with constraints. > > I can only set a referencial integrity between these tables when there are > no data, even if there are no change to referential integrity violation.
-
- 10 10月, 2000 7 次提交
-
-
由 Philip Warner 提交于
- Support for 'isstrict' procedure attribute. - Disable --blobs and --table (replaced prior to attempting to fix sequence dump problems)
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
-
- 09 10月, 2000 6 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
process, the need for changes to the FAQ_SCO document was uncovered. The attach patch file implements thost changes. Billy G. Allie
-
由 Peter Eisentraut 提交于
installing into a shared location. Also Makefile.global organizational cleanup.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
couldn't produce a full patch using cvs diff -c this time since I have created new files and anonymous cvs usage doesn't allow you to adds. I'm supplying the modified src/interfaces/jdbc as a tarball at : http://www.candleweb.no/~gunnar/projects/pgsql/postgres-jdbc-2000-10-05.tgz The new files that should be added are : ? org/postgresql/PGStatement.java ? org/postgresql/ObjectPool.java ? org/postgresql/ObjectPoolFactory.java There is now a global static pool of free byte arrays and used byte arrays connected to a statement object. This is the role of the new PGStatement class. Access to the global free array is synchronized, while we rely on the PG_Stream synchronization for the used array. My measurements show that the perfomance boost on this code is not quite as big as my last shot, but it is still an improvement. Maybe some of the difference is due to the new synchronization on the global array. I think I will look into choosing between on a connection level and global level. I have also started experimented with improving the performance of the various conversions. The problem here is ofcourse related handle the various encodings. One thing I found to speed up ResultSet.getInt() a lot was to do custom conversion on the byte array into int instead of going through the getString() to do the conversion. But I'm unsure if this is portable, can we assume that a digit never can be represented by more than one byte ? It works fine in my iso-latin-8859-1 environment, but what about other environments ? Maybe we could provide different ResultSet implementations depending on the encoding used or delegate some methods of the result set to an "converter class". Check the org/postgresql/jdbc2/FastResultSet.java in the tarball above to see the modified getInt() method. Regards, Gunnar
-
- 08 10月, 2000 7 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
for the library. not sure if this will cause problems on other platforms, but if it does it can be easily fixed. Also remove the references to the GeekGadgets includes as the majority of users don't have them installed and they foul the build process. We can document that adding them if you have them installed is a good idea. David Reid
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Tatsuo Ishii 提交于
This is equivalent to postmaster's -S option.
-
由 Bruce Momjian 提交于
> > For a while I though it might be because we are using an alpha TAS in > > the spinlock rather than the old semaphore. I replaced our spinlock > > with the standard one and it made no difference. We have been running > > with our spinlock implementation for nearly 2 months on a production > > database now without a hitch, so I think it is ok. Did I ever submit > > any patches for the Alpha spinlock? > > Not that I recall. We did get some advice from some Alpha gurus at DEC > who seemed to think the existing TAS code is OK. What was it that you > felt needed to be improved? The current code uses semaphores, which has the advantage that it works well even on multi-processor machines, but the disadvantage that it is not the fastest way possible. Writing a spinlock on Alpha for SMP machines is very difficult, as you need to deal with memory barriers. A real mess. But then one of the people at Compaq pointed out to us that there is a ready-made routine on Alpha. We implemented it with the two patches below. I ran tests with lots of parallel back-ends and got around a 10% speed increase. I include the two patches. Perhaps some of the other people running Tru64 can have a look at these as well. Cheers, Adriaan Joubert
-