, 26/02/2005 15:50 -0500, Bruce Momjian :
Other than that the other conversion files were already named fine, e.g.
ascii_to_utf_8 (no UNICODE), however it is utf_8 and not utf8. I am
unsure how to handle these.
General remark about the spelling of this encoding:
The correct encoding name
Hmm ...
First line of thought: we surely must not insert a snprintf
into libpq.so unless it is 100% up to spec *and* has no
performance issues ... neither of which can be claimed of the
CVS-tip version.
Second line of thought: libpq already feels free to insert
allegedly up-to-spec
Markus Bertheau ? wrote:
? ???, 26/02/2005 ? 15:50 -0500, Bruce Momjian ?:
Other than that the other conversion files were already named fine, e.g.
ascii_to_utf_8 (no UNICODE), however it is utf_8 and not utf8. I am
unsure how to handle these.
General remark about the spelling of
This patch uses our own snprintf() only when NLS support is enabled, and
I added support for %qd and %I64d in snprintf. We might need those in
the final version if it is exported to apps.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
Peter Eisentraut wrote:
Am Mittwoch, 2. M?rz 2005 15:48 schrieb Bruce Momjian:
This patch uses our own snprintf() only when NLS support is enabled, and
I added support for %qd and %I64d in snprintf. We might need those in
the final version if it is exported to apps.
test -a is not
Magnus Hagander wrote:
Hmm ...
First line of thought: we surely must not insert a snprintf
into libpq.so unless it is 100% up to spec *and* has no
performance issues ... neither of which can be claimed of the
CVS-tip version.
Second line of thought: libpq already feels free to
Am Mittwoch, 2. März 2005 16:50 schrieb Bruce Momjian:
Right. It is Unix that has the problem. It seems we are supplying a
special snprintf() only so gettext() in libintl will use ours instead of
the operating system's. Isn't there a way to target just that library
for our replacement
On Wed, Feb 16, 2005 at 07:50:28PM -0500, Tom Lane wrote:
Second iteration of buffer manager rewrite. This uses the idea of a
usage counter instead of just a recently-used flag bit. I allowed the
counter to go up to 5, but some playing around with that value would
be interesting. (Tweak
Bruce Momjian pgman@candle.pha.pa.us writes:
The correct encoding name is UTF-8.
True, but Peter says the ANSI standard calls it UTF8 so that's what I
used.
What SQL99 actually says is
- UTF8 specifies the name of a character repertoire that consists
of every character
Peter Eisentraut wrote:
Am Mittwoch, 2. M?rz 2005 16:50 schrieb Bruce Momjian:
Right. It is Unix that has the problem. It seems we are supplying a
special snprintf() only so gettext() in libintl will use ours instead of
the operating system's. Isn't there a way to target just that
On Wed, Mar 02, 2005 at 06:35:01PM +0100, Stefan Hans wrote:
http://developer.postgresql.org/docs/postgres/kernel-resources.html
16.5.1
FreeBSD
...
$ systcl -w kern.ipc.shmall=32768
$ systcl -w kern.ipc.shmmax=134217728
$ systcl -w kern.ipc.semmap=256
Linux
...
$ systcl
Bruce Momjian pgman@candle.pha.pa.us writes:
This patch uses our own snprintf() only when NLS support is enabled,
I see no point in this; it does not solve any problem we need solved,
only complicate the configuration behavior even more.
I added support for %qd and %I64d in snprintf.
I
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
This patch uses our own snprintf() only when NLS support is
enabled,
I see no point in this; it does not solve any problem we need solved,
only complicate the configuration behavior even more.
I think this is analogous to
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
This patch uses our own snprintf() only when NLS support is enabled,
I see no point in this; it does not solve any problem we need solved,
only complicate the configuration behavior even more.
Peter answered this.
I added
Mark Wong [EMAIL PROTECTED] writes:
CVS from 20050301 [ plus clock-sweep buffer manager ] :
http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/
throughput 5483.01
I only ran this for 30 minutes, as opposed to 60, but it looks
promising.
So about a 50% increase
On Wed, Mar 02, 2005 at 08:48:35PM -0500, Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
CVS from 20050301 [ plus clock-sweep buffer manager ] :
http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/
throughput 5483.01
I only ran this for 30 minutes, as opposed to 60,
Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
CVS from 20050301 [ plus clock-sweep buffer manager ] :
http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/
throughput 5483.01
I only ran this for 30 minutes, as opposed to 60, but it looks
promising.
So
Bruce Momjian pgman@candle.pha.pa.us writes:
This is HUGE. Was it because of the clock sweep?
No, it was because of the elimination of the global BufMgrLock.
Clock sweep is the price we had to pay to get that ...
regards, tom lane
---(end of
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
This is HUGE. Was it because of the clock sweep?
No, it was because of the elimination of the global BufMgrLock.
Clock sweep is the price we had to pay to get that ...
Wow, certainly stunning. Was it a big benefit only for SMP
Bruce Momjian pgman@candle.pha.pa.us writes:
Was it a big benefit only for SMP machines?
Probably. I did some simple pgbench checks and found that the new code
seemed no better than the old on a one-processor machine. However, as
long as it's not worse for a uniprocessor, who cares?
It would
I found it useful to be able to look at what relations are occupying the
cache (mainly for debugging and comparing with page estimates).
I am wondering if it might be a useful addition generally?
How it works a SRF called dump_cache() is created, which is then exposed
as system view pg_dump_cache.
Mark Kirkwood wrote:
does not worry too much about a consistent view of the buffer
contents (as I didn't want it to block all other activity!).
I don't like accessing shared data structures without acquiring the
appropriate locks; even if it doesn't break anything, it seems like just
asking for
22 matches
Mail list logo
