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
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
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 of
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,
Hello
I see the following
proba= select * from pg_language;
lanname |lanispl|lanpltrusted|lanplcallfoid|lancompiler
+---++-+--
internal|f |f |0|n/a
lisp|f |f |
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
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 use
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
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 = '=',
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 } [ ... ] ]
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
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 other
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
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 together.
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.
It may be
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
tests:
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
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 whether a given
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 |
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 could
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 occured to me
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
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
23 matches
Mail list logo
