Peter Eisentraut <[EMAIL PROTECTED]> writes:
> This must have been an artifact from the time when part of the Postgres
> system was written in Lisp. A Lisp procedural language never actually
> existed in PostgreSQL.
[ Digs in archives... ] The pg_language entry that Vladimir refers to
was still
Marko Kreen wrote:
>
> On Sat, May 05, 2001 at 06:43:51PM -0400, mlw wrote:
> > Marko Kreen wrote:
> > > On Sat, May 05, 2001 at 01:09:38PM -0400, mlw wrote:
> > > > A small debate started with bad performance on ReiserFS. I pondered the likely
> > > > advantages to raw device access. It also occ
* Marko Kreen <[EMAIL PROTECTED]> [010505 17:39] wrote:
>
> There already exist bazillion filesystems, _some_ of them should
> be usable for PostgreSQL too :)
>
> Besides resource waste there are others problems with app-level
> fs:
>
> * double-buffering and incompatibilities of avoiding that
On Sat, May 05, 2001 at 06:43:51PM -0400, mlw wrote:
> Marko Kreen wrote:
> > On Sat, May 05, 2001 at 01:09:38PM -0400, mlw wrote:
> > > A small debate started with bad performance on ReiserFS. I pondered the likely
> > > advantages to raw device access. It also occured to me that the FAT file sys
Marko Kreen wrote:
>
> On Sat, May 05, 2001 at 01:09:38PM -0400, mlw wrote:
> > A small debate started with bad performance on ReiserFS. I pondered the likely
> > advantages to raw device access. It also occured to me that the FAT file system
> > is about as close to a managed raw device as one c
Vladimir V. Zolotych writes:
> I see the following
>
> proba=> select * from pg_language;
> lanname |lanispl|lanpltrusted|lanplcallfoid|lancompiler
> +---++-+--
> internal|f |f |0|n/a
> lisp|f |f |
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > There's a TODO item to make elog(LOG) a separate level. I propose the
> > name INFO. It would be identical to DEBUG in effect, only with a
> > different label.
>
> This conveys nothing to my mind. How should I determine whethe
This is just a quick announcement that we have now branched off v7.1.x
from the main development tree, and are starting to dive into development
of v7.2 ...
There have been several changes since v7.1 was released, including:
Fix for numeric MODULO operator (Tom)
pg_dump fixes (Philip)
pg_dump c
On Sat, May 05, 2001 at 04:54:07PM +0300, Vladimir V. Zolotych wrote:
> I see the following
>
> proba=> select * from pg_language;
> lisp|f |f |0|/usr/ucb/liszt
> Would you mind to tell me is it possible to use Lisp
> as procedural language ? Which Lisp (e.g Emac
On Sat, May 05, 2001 at 01:09:38PM -0400, mlw wrote:
> A small debate started with bad performance on ReiserFS. I pondered the likely
> advantages to raw device access. It also occured to me that the FAT file system
> is about as close to a managed raw device as one could get. So I did some
> test
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> > Yes, this double-writing is a problem. Suppose you have your WAL on a
>> > separate drive. You can fsync() WAL with zero head movement. With a
>> > log based file system, you need two head movements, so you have gone
>> > from zero movements to two.
Lincoln Yeoh wrote:
>
> At 02:09 AM 5/4/01 -0500, Thomas Swan wrote:
> > I think it's worth noting that Oracle has been petitioning the
> > kernel developers for better raw device support: in other words,
> > the ability to write directly to the hard disk and bypassing the
> > filesystem all toge
A small debate started with bad performance on ReiserFS. I pondered the likely
advantages to raw device access. It also occured to me that the FAT file system
is about as close to a managed raw device as one could get. So I did some
tests:
The hardware:
A PII system running Linux 7.0, with 2.2.16
At 02:09 AM 5/4/01 -0500, Thomas Swan wrote:
> I think it's worth noting that Oracle has been petitioning the
> kernel developers for better raw device support: in other words,
> the ability to write directly to the hard disk and bypassing the
> filesystem all together.
But there could be othe
Beautiful! That fixed my problem. One thing that might be
useful is to update the Index method-extension documentation
on the web site to reflect this problem a bit...if somebody
just wants to get a working index, it can be a bit misleading.
I'll probably go and see if I can construct a few wor
postgresql=> \h create table
Command: CREATE TABLE
Description: Creates a new table
Syntax:
CREATE [ TEMPORARY | TEMP ] TABLE table (
column type
[ NULL | NOT NULL ] [ UNIQUE ] [ DEFAULT value ]
[column_constraint_clause | PRIMARY KEY } [ ... ] ]
David McWherter <[EMAIL PROTECTED]> writes:
> But I still get the issue that my queries don't seem to trigger the
> GiST indexes to be used. Perhaps the problem is that the system
> just thinks that the query doesn't need an index to increase
> performance, i've only got about a dozen elements i
[ thread renamed and cross-posted to pghackers, since this isn't only
about JDBC anymore ]
Barry Lind <[EMAIL PROTECTED]> writes:
> The basic issue I have it that the server is providing an API to the
> client to get the character encoding for the database and that API can
> report incorrect in
So, I've migrated my code to do the TOAST'ing thing required of 7.1
clients, and I've updated my operator to use the areaselectors:
CREATE OPERATOR = (
leftarg = graph,
rightarg = graphrange,
procedure = graph_inrange,
commutator = '=',
restri
David McWherter <[EMAIL PROTECTED]> writes:
> I've tried adding the parameters 'restrict = eqsel' and 'join = eqjoinsel'
> to the datatype operators, but that doesn't seem to change anything.
You might have better luck if you use area-related selectivity
estimators. Your problem seems to be that
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There's a TODO item to make elog(LOG) a separate level. I propose the
> name INFO. It would be identical to DEBUG in effect, only with a
> different label.
This conveys nothing to my mind. How should I determine whether a given
elog call ought to
David,
GiST prior 7.1 was broken in several respects. Please,
try 7.1 and examples from contrib/intarray. It should works.
btw, you'll have compress function actually works.
Regards,
Oleg
On Sat, 5 May 2001, David McWherter wrote:
>
> Sure. My postgresql version is 7.0
Hello
I see the following
proba=> select * from pg_language;
lanname |lanispl|lanpltrusted|lanplcallfoid|lancompiler
+---++-+--
internal|f |f |0|n/a
lisp|f |f |0|/usr/ucb/lisz
Sure. My postgresql version is 7.0.2.
My database has a datatype called graph that looks like this:
CREATE TYPE graph (
internallength = VARIABLE,
input = graph_in,
output = graph_out
);
CREATE OPERATOR ~ (
leftarg = graph,
rightarg = graph,
pr
David,
could you provide more info (scheme, query, postgresql version)
Regards,
Oleg
On Sat, 5 May 2001, David McWherter wrote:
>
> I've been doing some research work using the GiST indexes,
> but I persistently develop a problem where the system doesn't
> make use
* Peter Eisentraut <[EMAIL PROTECTED]> [010505 02:06] wrote:
> There's a TODO item to make elog(LOG) a separate level. I propose the
> name INFO. It would be identical to DEBUG in effect, only with a
> different label. Additionally, all DEBUG logging should either be
> disabled unless the debug
There's a TODO item to make elog(LOG) a separate level. I propose the
name INFO. It would be identical to DEBUG in effect, only with a
different label. Additionally, all DEBUG logging should either be
disabled unless the debug_level is greater than zero, or alternatively
some elog(DEBUG) calls
I've been doing some research work using the GiST indexes,
but I persistently develop a problem where the system doesn't
make use of the indexes during the execution of a query. If
I use the examples provided here:
http://wit.mcs.anl.gov/~selkovjr/pg_extensions/
For instance, and I pla
28 matches
Mail list logo
