On Sun, Jul 29, 2007 at 06:31:04PM -0400, Andrew Dunstan wrote:
>
>
> Andreas Pflug wrote:
> >Andrew Dunstan wrote:
> >
> >>>
> >>>
> I have no idea why that's done - it goes back to the origins of the
> syslogger - probably because someone mistakenly thinks all WIndows
> tex
On Sun, Jul 29, 2007 at 07:43:34PM -0400, Andrew Dunstan wrote:
>
>
> Andreas Pflug wrote:
> >Andrew Dunstan wrote:
> >
> >>I have no idea why that's done - it goes back to the origins of the
> >>syslogger - probably because someone mistakenly thinks all WIndows
> >>text files have to have CRLF
Magnus Hagander wrote:
However, the problem is that in backporting it we'd make a slight
behaviour change - the log file just gets LF instead of CRLF line
endings. I'm inclined to say that's a better result than living with the
bug, though.
Can't we add back the CRLF combo when writing
One of the ideas for pgadmin for the future will be a statistics table
visualizer which amongst other things could chart the histograms so people can
see if they represent the distribution of data they expect.
To do this pgadmin would need access to convert_to_scalar so it understands
where to pl
On Mon, Jul 30, 2007 at 01:04:35PM +0100, Gregory Stark wrote:
>
> One of the ideas for pgadmin for the future will be a statistics table
> visualizer which amongst other things could chart the histograms so people can
> see if they represent the distribution of data they expect.
>
> To do this p
Oleg Bartunov wrote:
> > OK, here is what I am thinking. If we make default_text_search_config
> > super-user-only, then the user can't do SET (using "zero_damaged_pages"
> > as a superuser-only example):
> >
> > test=> set zero_damaged_pages = on;
> > ERROR: permission denied to set para
Hi,
On Wed, 2007-07-25 at 20:22 -0700, Joshua D. Drake wrote:
> > I'm checking into this, but it may take a few days to get an answer
> > (particularly since I'm planning to take Friday through Monday off).
>
> Well if we go RHEL why not CentOS5 and just call it good?
...because RHEL and CentOS
Jim Nasby wrote:
> On Jul 27, 2007, at 1:49 AM, Alvaro Herrera wrote:
>> ITAGAKI Takahiro wrote:
>>> "Simon Riggs" <[EMAIL PROTECTED]> wrote:
>>>
Read the heap blocks in sequence, but make a conditional lock for
cleanup on each block. If we don't get it, sleep, then try again when we
Jignesh Shah's scalability testing on Solaris has revealed further
tuning opportunities surrounding the start and end of a transaction.
Tuning that should be especially important since async commit is likely
to allow much higher transaction rates than were previously possible.
There is strong cont
Hi,
We are trying to sort the index tuples before inserting them into hash buckets,
to improve build speed.
Here is our plan:
1. Build a spool that contains all the index tuples to be inserted into the
buckets. - this is done.
2. sort the index tuples in the spool according to the bucket nu
Bruce Momjian wrote:
> We have to decide if we want a GUC default_text_search_config, and if so
> when can it be changed.
>
> Right now there are three ways to create a tsvector (or tsquery)
>
> ::tsvector
> to_tsvector(value)
> to_tsvector(config, value)
>
> (ignoring plainto_
Devrim GÜNDÜZ wrote:
Hi,
RHEL has better performance than CentOS -- I guess it is the compiler
options that Red Hat is using while compiling their RPMs.
I have performed a test using OSDL test suite a few months ago on a
system that has:
* 8 x86_64 CPUs @ 3200.263
* 16 Gigabytes of RAM
* Pos
Hi,
On Mon, 2007-07-30 at 19:14 -0700, Joshua D. Drake wrote:
> > and RHEL performed much better than CentOS.
>
> Not to be unkind, but I doubt that on an identical configuration.
Since I don't have the permission to distribute the benchmark results, I
will be happy to spend time for re-running
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > 3) Remove default_text_search_config and require the
> >configuration to be specified in each function call.
> >
> > If we remove default_text_search_config, it would also make ::tsvector
> > casting useless as well.
>
> OK, I just foun
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > I think we might need additional "freezing-xmax" operations to avoid
> > XID-wraparound in the first path of vacuum, though it hardly occurs.
>
> I'm not sure I follow. Can you elaborate? Do you mean storing a
> separate relfrozenxmax for each tabl
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
>
> > > 3) Remove default_text_search_config and require the
> > > configuration to be specified in each function call.
> > >
> > > If we remove default_text_search_config, it would also make ::tsvector
> > > casting use
ITAGAKI Takahiro wrote:
>
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > > I think we might need additional "freezing-xmax" operations to avoid
> > > XID-wraparound in the first path of vacuum, though it hardly occurs.
> >
> > I'm not sure I follow. Can you elaborate? Do you mean storing a
Arjen van der Meijden wrote:
> Afaik Tom hadn't finished his patch when I was testing things, so I don't
> know. But we're in the process of benchmarking a new system (dual quad-core
> Xeon) and we'll have a look at how it performs in the postgres 8.2dev we
> used before, the stable 8.2.4 and a
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> On Mon, 2007-07-30 at 19:14 -0700, Joshua D. Drake wrote:
>>> and RHEL performed much better than CentOS.
>> Not to be unkind, but I doubt that on an identical configuration.
> Each test took 1-2 days -- I will insist that CentOS pe
Moving to -hackers.
On Jul 27, 2007, at 1:22 PM, Stuart wrote:
Does Postgresql have a function like ascii() that will
return the unicode codepoint value for a utf8 character?
(And symmetrically same for question chr() of course).
I didn't find anything in the docs so I think the answer
is no wh
Hi,
On Mon, 2007-07-30 at 23:36 -0400, Tom Lane wrote:
> > Each test took 1-2 days -- I will insist that CentOS performs poorer
> > than RHEL.
>
> I'm finding that hard to believe too.
I have felt the same, that's why I repeated the test twice.
> There isn't any "secret sauce" in the RHEL build
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> On Mon, 2007-07-30 at 23:36 -0400, Tom Lane wrote:
>> There isn't any "secret sauce" in the RHEL build process
> Really? Are the compiler options, etc, public?
Certainly. If you doubt it, try comparing pg_config output for the RHEL
On 31-7-2007 5:07 Alvaro Herrera wrote:
Arjen van der Meijden wrote:
Afaik Tom hadn't finished his patch when I was testing things, so I don't
know. But we're in the process of benchmarking a new system (dual quad-core
Xeon) and we'll have a look at how it performs in the postgres 8.2dev we
us
23 matches
Mail list logo
