Dear Team,
I've read your comments. No, I don't think
that MVD's are the best thing since sliced breadbut they do have a certain
"simplicity" that seems to hold the key to high speed analysis of large volumes
of streaming data from the "eyes" of a robot. This stream of data must be
q
On Thu, 2002-05-02 at 05:33, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > So, how does one determine the current schema for temporary tables,
> > i.e. what name would be in search_path if it wasn't implicitly included?
>
> The temp schema is pg_temp_nnn where nnn is your B
Ron Snyder wrote:
>
> I've got a table, view, and rules as below. The permissions are set up in
> such a way that I can use it just fine as myself via psql. When I try to
> access the data using an ms access interface via odbc, I get the first
> record in the view, but any attempts to go to othe
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> But does Postgresql visit the older tuples first moving to the newer ones,
> or the newer ones first?
It's going to visit them *all*. Reordering won't improve the
performance.
FWIW I think that with the present implementation of btree, the newer
tuple
Peter Bierman <[EMAIL PROTECTED]> writes:
> Is fork() disallowed after shutdown starts?
>>
>> No, it's allowed. But, depending upon timing, the new process may be
>> hammered with a SIGTERM right away (maybe even before main()).
Good point. The fork is executed with SIGTERM blocked --- but the
At 02:10 PM 5/1/02 -0400, Tom Lane wrote:
>Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > My limited understanding of current behaviour is the search for a valid
> > row's tuple goes from older tuples to newer ones via forward links
>
>No. Each tuple is independently indexed and independently visit
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> So, how does one determine the current schema for temporary tables,
> i.e. what name would be in search_path if it wasn't implicitly included?
The temp schema is pg_temp_nnn where nnn is your BackendId (PROC array
slot number). AFAIK there isn't a
Neil Conway <[EMAIL PROTECTED]> writes:
> I've been taking a look at fixing the TODO item:
> o Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)
> My first plan of attack was to replace the current list of ResTargets
> in InsertStmt with a list of lists.
If you look at the SQL sp
On Thu, 2 May 2002, Ian Barwick wrote:
> Tom Lane wrote:
> [snipped]
> > My gut feeling is that "\d mytab" should tell you about the same
> > table that "select * from mytab" would find. Anything else is
> > probably noise to you --
>
> General consistency with SELECT behaviour sounds right to
[EMAIL PROTECTED] wrote:
>
> > mlw <[EMAIL PROTECTED]> writes:
> > > Just out of curiosity, does PostgreSQL have a mission statement?
>
> > Nope. Given the wide variety of views among the developer community,
> > I think we'd have a tough time agreeing on a mission statement, unless
> > it was
[EMAIL PROTECTED] wrote:
> > mlw <[EMAIL PROTECTED]> writes:
> > > Just out of curiosity, does PostgreSQL have a mission statement?
>
> > Nope. Given the wide variety of views among the developer community,
> > I think we'd have a tough time agreeing on a mission statement, unless
> > it was so g
On Wed, May 01, 2002 at 02:24:30PM -0400, mlw wrote:
> Just out of curiosity, does PostgreSQL have a mission statement?
>
> If so, where could I find it?
>
> If not, does anyone see a need?
"Provide a really good database and have fun doing it"
--
David Terrell | "War is peace,
P
> INSERT INTO t1 (c1) VALUES (1), (2);
>
> would be executed in a similar fashion to:
>
> INSERT INTO t1 (c1) VALUES (1);
> INSERT INTO t1 (c1) VALUES (2);
>
> Does this sound reasonable?
I debated doing the above too. In fact, I had a partial
implementation at one point.
Howeve
> mlw <[EMAIL PROTECTED]> writes:
> > Just out of curiosity, does PostgreSQL have a mission statement?
> Nope. Given the wide variety of views among the developer community,
> I think we'd have a tough time agreeing on a mission statement, unless
> it was so generic as to be meaningless ...
Wel
Hi all,
I've been taking a look at fixing the TODO item:
o Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)
My first plan of attack was to replace the current list of ResTargets
in InsertStmt with a list of lists. The problem with that approach is
that:
(a) the InsertStmt
> I suppose arrays are PostgreSQL's equivalent of multi-valued data (is it
> possible to have arrays of arrays?) So it could be argued that
> PostgreSQL already provides part of what Arthur wants.
It seems to me that there would be a whopping lot of value to the exercise of
figuring out some wa
mlw <[EMAIL PROTECTED]> writes:
> Just out of curiosity, does PostgreSQL have a mission statement?
Nope. Given the wide variety of views among the developer community,
I think we'd have a tough time agreeing on a mission statement, unless
it was so generic as to be meaningless ...
Tom Lane wrote:
> psql's \d command hasn't the foggiest idea that there might now be more
> than one pg_class entry with the same relname. It needs to be taught
> about that --- but even before that, we need to work out schema-aware
> definitions of the wildcard expansion rules for psql's backsla
At 1:26 AM -0400 4/30/02, Tom Lane wrote:
>I've been looking into Francois Suter's recent reports of Postgres not
>shutting down cleanly on Mac OS X 10.1.
>
>Now here's what I see in the case of shutting down the OS X system:
>
>2002-04-30 00:25:35 [376]DEBUG: pmdie 15
>2002-04-30 00:25:35 [3
On Wed, 2002-05-01 at 19:37, [EMAIL PROTECTED] wrote:
> I also did some internet research on the subject of "multi valued"
database theory. I know that this is the basis for the "Pick" database
system
For those who aren't familiar with PICK, it is an untyped database
(apart from weak types prov
Dear Team,
I have been monitoring this list for quite some
time now and have been studying PostGreSQL for a while. I also did some
internet research on the subject of "multi valued" database theory. I know
that this is the basis for the "Pick" database system, FileMaker Pro, "D3", and
a
Neil Conway <[EMAIL PROTECTED]> writes:
> nconway=> prepare q2 as select $1;
> ERROR: Parameter '$1' is out of range
> (You'll see the same parse error with simply "select $1;")
You need to tell the parser the number of parameters to expect and their
datatypes. This is what the last two argume
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> My limited understanding of current behaviour is the search for a valid
> row's tuple goes from older tuples to newer ones via forward links
No. Each tuple is independently indexed and independently visited.
Given the semantics of MVCC I think that's c
Hi Tom,
(Please correct me where I'm wrong)
Is it possible to reduce the performance impact of dead tuples esp when the
index is used? Right now performance goes down gradually till we vacuum
(something like a 1/x curve).
My limited understanding of current behaviour is the search for a valid
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Since dead, or yet to be visible tuples affect the plan that should be
> taken (until vacuum anyway) are these numbers reflected in the stats
> anywhere?
Analyze just uses SnapshotNow visibility rules, so it sees the same set
of tuples that you would see
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> ERROR: Unrecognized language specified in a CREATE FUNCTION: 'plpgsql'.
> Pre-installed languages are SQL, C, and internal.
> Additional languages may be installed using 'createlang'.
> I've done a "createlang plpgsql templa
I've run into an interesting issue. A very long running transaction
doing data loads is getting quite slow. I really don't want to break
up the transactions (and for now it's ok), but it makes me wonder what
exactly analyze counts.
Since dead, or yet to be visible tuples affect the plan that sh
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
[snap]
> How do I get this to work?
>
> Chris
I think i did this:
CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
'/usr/local/pgsql/lib/plpgsql.so', 'plpgsql_call_handler' LANGUAGE 'C';
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' H
Hi all,
I'm having problems restoring a dump. I get this:
You are now connected as new user chriskl.
ERROR: Unrecognized language specified in a CREATE FUNCTION: 'plpgsql'.
Pre-installed languages are SQL, C, and internal.
Additional languages may be installed using 'createlang
29 matches
Mail list logo
