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
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
* 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
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
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
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
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
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 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 = '=',
restri
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
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 wor
[ 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
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
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
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
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.
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
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
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
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 c
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 <[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
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
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 c
28 matches
Mail list logo
