Adrian 'Dagurashibanipal' von Bidder wrote:
I'm just saying that there are
*some* small arcane details in postgres, too (although, at least, they
don't affect stability, just performance).
Indeed you are right... Pg has its own collection of arcane details too,
but hopefully the culture of Pos
> (i.e. arcane
> little "need to know" things that trap all but the initiated...
So, for postgres, that means:
- a good thing the autovacuum thingy is coming along
- postgres should auto-tune itself - the *cost could perhaps be
adjusted after some statistics have been collected, and there shou
The Oracle system stops from time to time because of various arcane
reasons. You get the error message, look it up on alltheweb.com, and
fix it. The whole system is bogus. It DEMANDS a full time DBA.
PostgreSQL does not.
I could be accused of being cynical here (gosh)... but I think thats
On Wed, 2003-01-15 at 20:15, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
> >> Hm. I just finished verifying that CVS tip builds and passes cleanly
> >> on both HPUX and Linux (Red Hat 8.0). So either you've got a build
> >> error (did
> >> Hm. I just finished verifying that CVS tip builds and passes cleanly
> >> on both HPUX and Linux (Red Hat 8.0). So either you've got a build
> >> error (did you do a "make clean" after your last update?) or there's
> >> some really weird platform dependency involved. What's your platform
>
Gavin Sherry wrote:
On Wed, 15 Jan 2003, mlw wrote:
I just wanted to post this note.
I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how m
On Wed, 15 Jan 2003, mlw wrote:
> I just wanted to post this note.
>
> I have been in Oracle hell for four days now, and in between the 5
> minutes of work and the hours of watings, dealing with table spaces,
> extents, and all that, I just keep thinking about how much easier
> PostgreSQL is t
I just wanted to post this note.
I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how much easier
PostgreSQL is to work with.
We all may bitch and moan about
Fernando Nasser writes:
> THe SQL Flagger is only required for Intermediate SQL. SQL'92 23.4 says Entry
> SQL may, but are not required to.
SQL 92 is obsolete. In SQL 99 and later it's a core feature.
> If I understood it correctly, we only need a new elog level and add a few elog
> calls in s
Eric B.Ridge writes:
> What about expanding the history capabilities of psql's history command
> (\s) to include something more bash/tcsh-like? For example:
> !insert
>-- execute the last command that began with "insert"
> !23
>-- execute item #23 in my history
If you per
Lamar Owen wrote:
On Wednesday 15 January 2003 09:20, Justin Clift wrote:
Sound like a plan? Will also need someone else with a Solaris 8 SPARC
system to try the packages out too, just in case there are weird library
dependencies happening that might catch us out.
I have access to several (t
[EMAIL PROTECTED] writes:
> Sample Code
> create table teste(serie integer,aula text[][]);
> //it´s ok when insert this
> insert into teste values (1,'{{"004","009"},{"009"},{""},
> {"001","002"}}');
> //But when I insert this..
> insert into teste values
> (1,'{{"004","009","002"},{"009","001"},{"
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
>> Hm. I just finished verifying that CVS tip builds and passes cleanly
>> on both HPUX and Linux (Red Hat 8.0). So either you've got a build
>> error (did you do a "make clean" after your last update?) or there
On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Last update was about 5 minutes after Bruce's header fix went into
> > place.
> Hm. I just finished verifying that CVS tip builds and passes cleanly
> on both HPUX and Linux (Red Hat 8.0). So either you've
Rod Taylor <[EMAIL PROTECTED]> writes:
> Last update was about 5 minutes after Bruce's header fix went into
> place.
Hm. I just finished verifying that CVS tip builds and passes cleanly
on both HPUX and Linux (Red Hat 8.0). So either you've got a build
error (did you do a "make clean" after your
Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
>
> > We have roles?
>
> Until two days ago I was under the impression that roles were schema
> objects, but apparently this is not the case, and it seems that roles are
> really just an extension of our group concept.
Yep. We have alrea
Rod Taylor <[EMAIL PROTECTED]> writes:
> Index Scan using inet_idx1 on inet_tbl (cost=3D0.00..4.68 rows=3D7
> width=3D64)
>Index Cond: ((i > '192.168.1.0/24'::inet) AND (i <=3D
> '192.168.1.255'::inet))
>Filter: (i << '192.168.1.0/24'::inet)
> (3 rows)
That's the expected plan ...
> reg
Rod Taylor <[EMAIL PROTECTED]> writes:
> With Bruce's patch came a few others -- plus a recompile with all
> updates.
Which patch exactly? The regression test was still passing for me
as of yesterday's sources plus the large planner commit I just made.
I'm resyncing to CVS tip at the moment ...
On Wed, 2003-01-15 at 15:29, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > With Bruce's patch came a few others -- plus a recompile with all
> > updates.
>
> Which patch exactly? The regression test was still passing for me
> as of yesterday's sources plus the large planner commit
With Bruce's patch came a few others -- plus a recompile with all
updates.
> ... and that's the expected result. So why'd you get a different result
> while running the regression test? Curiouser and curiouser...
--
Rod Taylor <[EMAIL PROTECTED]>
PGP Key: http://www.rbt.ca/rbtpub.asc
signat
regression=#
regression=#
regression=# create index inet_idx1 on inet_tbl(i);
CREATE INDEX
regression=# set enable_seqscan to off;
SET
regression=# explain select * from inet_tbl where
i<<'192.168.1.0/24'::cidr;
QUERY
PLAN
-
If you get it working, I can remove the ORDER BY's I added.
---
Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Looks like some ORDER BY statements would be useful.
>
> To do what? Those queries should already
Rod Taylor <[EMAIL PROTECTED]> writes:
> Looks like some ORDER BY statements would be useful.
To do what? Those queries should already be producing indexscan plans.
If you're not getting the expected answers, there is something that
needs to be fixed, not papered over.
Please try
create index i
Lamar Owen wrote:
On Wednesday 15 January 2003 09:20, Justin Clift wrote:
Sound like a plan? Will also need someone else with a Solaris 8 SPARC
system to try the packages out too, just in case there are weird library
dependencies happening that might catch us out.
I have access to sever
Justin Clift writes:
> Also, am wondering if learning how to do "cross compiling" instead might
> be worthwhile. Don't yet know anything about it, but it gets mentioned
> in a lot of documents.
The hard part about cross-compiling is getting a cross-compiler
(especially if you have to build it yo
Christopher Kings-Lynne writes:
> We have roles?
Until two days ago I was under the impression that roles were schema
objects, but apparently this is not the case, and it seems that roles are
really just an extension of our group concept.
--
Peter Eisentraut [EMAIL PROTECTED]
--
Tom Lane wrote:
> Ian Barwick <[EMAIL PROTECTED]> writes:
> > On Sunday 12 January 2003 17:55, Bruce Momjian wrote:
> >> I can't say "don't use CHAR(n)" because there are valid reasons to use
> >> it.
>
> > I think what Tom is saying is "always use VARCHAR(n) unless you know
> > for sure CHAR(n) i
THe SQL Flagger is only required for Intermediate SQL. SQL'92 23.4 says Entry
SQL may, but are not required to.
This said, it is a nice to have feature for the reasons that Peter pointed out.
But as I understand it, this is a sort of warning feature, and depending on the
"extent of checking" o
OK, I have applied an patch to ORDER BY on those queries. I don't see
the ordering you have here, but this should fix it for you. I also
uppercased the keywords while I was in there.
---
Rod Taylor wrote:
-- Start of PGP si
On Wed, 15 Jan 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > It seems to me that the spec has a fairly hardwired notion of what types
> > should come out given the sql types. The biggest problems that I can
> > see are that it doesn't extend well to an extensible type syst
On Wednesday 15 January 2003 09:20, Justin Clift wrote:
> Sound like a plan? Will also need someone else with a Solaris 8 SPARC
> system to try the packages out too, just in case there are weird library
> dependencies happening that might catch us out.
I have access to several (two dozen) current
Stephan Szabo <[EMAIL PROTECTED]> writes:
> It seems to me that the spec has a fairly hardwired notion of what types
> should come out given the sql types. The biggest problems that I can
> see are that it doesn't extend well to an extensible type system and that
> in alot of cases it doesn't seem
Looks like some ORDER BY statements would be useful.
*** ./expected/inet.out Sat Jun 16 22:05:20 2001
--- ./results/inet.out Wed Jan 15 10:18:40 2003
***
*** 193,212
select * from inet_tbl where i<<'192.168.1.0/24'::cidr;
c|i
On Wed, 15 Jan 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Hmm, I think (but am not sure) that the spec bit
> > in SQL92 that addresses this is 9.3
> > Set operation result data types based on the
> > text in 7.10 query expression. It seems
> > to say to me that should a
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Hmm, I think (but am not sure) that the spec bit
> in SQL92 that addresses this is 9.3
> Set operation result data types based on the
> text in 7.10 query expression. It seems
> to say to me that should always be an
> approximate numeric (if 1.0 is an ap
Mark Kirkwood wrote:
I can get access to several boxes with Solaris 8 + gcc 2.95 ( maybe not
right-up-to-the minute latest patches, but fairly recently patched).
They are firewalled off from the internet with abolutely no chance of
external access, but I can build whatever is required ( Pg 7.3
On 14 Jan 2003 10:54:29 -0500, Robert Treat
<[EMAIL PROTECTED]> wrote:
>Changed = the number of pages that had to be modified.
This counts only pages changed due to heap tuple header updates
(FrozenTransactionId, hint bits). It does not count page changes due
to removal of dead tuples, cf. Julian
Justin Clift wrote:
Hi guys,
Have created a Solaris 8 Intel package for PostgreSQL 7.3.1, but don't
have any SPARC boxes here any more.
Does anyone have a SPARC box handy that would be available for
compiling PostgreSQL 7.3.1 on? It would need to be Solaris 8 (or
maybe 9), and have things l
38 matches
Mail list logo