On Tue, 2002-04-23 at 01:29, Martijn van Oosterhout wrote:
>
> The dumping is more of an extra, the original idea was to check for errors
> in the datafiles. Hence the working name of "pgfsck". At the moment the
> dumping dumps only tuples where xmax == 0 but I'm not sure if that's
> correct.
AF
> I'd like to implement *something* to help us collect information on what
> platforms actually have what features. This would be useful, for
> example, for figuring out whether any platforms are lacking 8 byte
> integers or are missing timezone infrastructure.
>
> I was thinking about something
I'd like to implement *something* to help us collect information on what
platforms actually have what features. This would be useful, for
example, for figuring out whether any platforms are lacking 8 byte
integers or are missing timezone infrastructure.
I was thinking about something like "make r
I was in Boston for a few days for a wedding. Never got time to be
online. I am back now. I will read my email and apply outstanding
patches tomorrow.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Also, for functions and operators the name alone is not sufficient to
>> uniquely identify the object. Type regproc currently throws an error
>> if asked to convert a nonunique function name; that severely limits its
>> usefulness. I'm
Tom Lane wrote:
> A variant of the idea of inventing functions is to extend the existing
> datatype 'regproc' to do this, and invent also 'regclass', 'regtype',
> 'regoperator' datatypes to do the lookups for the other object kinds.
> I proposed this in a different context last year,
> http:
The benchmarks will depend mostly on the depth of the Btree. Hashes
will be markedly faster only in the case(s) where descending into the
tree to produce a matching leaf node would take longer than walking to
the appropriate item in a hash.
Most of the time until the btree gets deep they are
On Mon, Apr 22, 2002 at 11:14:36AM -0500, Ross J. Reedstrom wrote:
> On Sun, Apr 21, 2002 at 07:28:32PM +1000, Martijn van Oosterhout wrote:
> >
> > http://svana.org/kleptog/pgsql/page.sgml.txt
> >
> > I don't know whatever SGML format this is using, so the layout is not great,
> > but the infor
Using current CVS (yesterday) I've rerun the benchmarks to see the
effects of various NAMEDATALEN settings.
3 times per setting.
First time is pgbench inserts (-s 5)
Second time is pgbench run (-t 3000 -s 5)
Third time is the postmaster during both of the above.
I'll run it again tonight on a
[tgl@rh1 preproc]$ make
bison -y -d preproc.y
conflicts: 2 reduce/reduce
This is not good.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregis
On Mon, 22 Apr 2002 15:04:22 -0700
"Dann Corbit" <[EMAIL PROTECTED]> wrote:
> Here is where a hashed index shines:
> To find a single item using a key, hashed indexes are enormously faster
> than a btree.
>
> That is typically speaking. I have not done performance benchmarks with
> PostgreSQL.
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 2:59 PM
> To: Dann Corbit
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] What is wrong with hashed index usage?
>
>
> On Mon, 22 Apr 2002 14:15:37 -0700
> "Dann Corbit" <[EMAIL PROTECTED]
On Mon, 22 Apr 2002 14:15:37 -0700
"Dann Corbit" <[EMAIL PROTECTED]> wrote:
> From here:
> http://osdb.sourceforge.net/
> We find this quote:
> "For you long-suffering OSDB PostgreSQL users, we offer
>
> --postgresql=no_hash_index
>
> to work around the hash index problems of OSDB with Postgre
Thanks Jean.
I will send a message to the ODBC list.
At least I didn't create the project in sourceforge
yet. I will try to get a cvs account at
Postgresql.org
as you said. :)
Thanks very much!!!
Francisco Jr.
___
From here:
http://osdb.sourceforge.net/
We find this quote:
"For you long-suffering OSDB PostgreSQL users, we offer
--postgresql=no_hash_index
to work around the hash index problems of OSDB with PostgreSQL V7.1 and
7.2. As always, let us know of any problems. May the source be with
you!"
Does
We are about to need to fix a fair number of places in client code
(eg, psql and pg_dump) that presently do things like
SELECT * FROM pg_attribute
WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'foo');
This does not work reliably anymore because there could be multiple
relations name
Martijn,
It may be useful to look at the pg_filedump utility located
at http://sources.redhat.com/rhdb/tools.html
This utility dumps out information at the page level and is
commented to help the user understand the format/content of
PostgreSQL heap/index/control files.
Cheers,
Patrick
---
I've been reading past threads, studying backend code, reviewing Alex
Pilosov's "cursor foo" patch (submitted last August/September, but never
applied), and conversing off list with a few people regarding a possible
implementation of Set Returning Functions (or SRF for short). Below is
my prop
On Sun, Apr 21, 2002 at 07:28:32PM +1000, Martijn van Oosterhout wrote:
>
> http://svana.org/kleptog/pgsql/page.sgml.txt
>
> I don't know whatever SGML format this is using, so the layout is not great,
> but the information should be accurate. I used it to create a program to
> dump the datafile
I've committed a bit more to variable.c to handle integer inputs to GUC
parameters (string and float were already supported). I've included the
cvs log message below.
Further changes aren't precluded of course, but the code now supports
string, integer, and floating point inputs to parameters (fo
Peter Eisentraut writes:
> [EMAIL PROTECTED] writes:
> > The most reason for patch are paremeters,
>
> Parameters already exist:
>
> peter ~$ cat test.sql
> \echo :x1
> \echo :x2
> peter ~$ pg-install/bin/psql -f test.sql -v x1=foo -v x2=bar
> foo
> bar
OK, positional parameters
--
@BABOLO
Hi,
> > > > Maybe to keep hostile users from filling up your disk?
>
> Actually, I was serious, not sarcastic, about that "maybe." Like
> Tom, I'm not entirely sure that it's necessary to add this complexity,
> because there are so many other ways to abuse the system.
I know... But we have to st
Le Dimanche 21 Avril 2002 02:11, Francisco Jr. a écrit :
> I'd like to know if there is already anybody working
> with something like this because I'm creating a new
> project at sourceforge.net and I don't want to overlap
> anywork already done :).
Maybe you should try contact the ODBC list whic
Hi All.
I've been reading all the thread and I want to add a few points:
You can set enable_seqscan=off in small or easy queries, but in large
queries index can speed parts of the query and slow other, so I think it is
neccesary if you want Postgres to become a Wide-used DBMS that the planner
cou
24 matches
Mail list logo
