Thank you all for the effort you put into response.
The biggest thing I want to avoid isn't so much having to parse through
the log files but to avoid turning on such extensive logging altogether.
I am not sure what kind of additional load logging to this extent may
add.
Looks like I am not
Hey everyone,
I'm reworking hierarchical queries and am adding a LEVEL pseudocolumn.
As it's a totally calculated attribute, what's the best way to handle
it keeping in mind that LEVEL is only used in a hierarchical query?
Looking at Evgen's patches, if he recognizes a hierarchical query and
On Mon, May 15, 2006 at 11:03:46AM -0400, Jonah H. Harris wrote:
I couldn't think of any pseudocolumns like this in PostgreSQL, but I
may just be brain-dead again. As it may be sorta similar, how were we
discussing handling rownum?
tableoid is a pseudo-column like you mean, perhaps you should
On 5/15/06, Martijn van Oosterhout kleptog@svana.org wrote:
tableoid is a pseudo-column like you mean, perhaps you should look how
that works.
I thought tableoid was a system column with a physical representation
on the tuple itself? I don't want any on-disk representation of my
On Mon, May 15, 2006 at 11:17:41AM -0400, Jonah H. Harris wrote:
On 5/15/06, Martijn van Oosterhout kleptog@svana.org wrote:
tableoid is a pseudo-column like you mean, perhaps you should look how
that works.
I thought tableoid was a system column with a physical representation
on the tuple
Mark Campbell wrote:
Hi All
I downloaded version 7.3 and compiled that.
First I had to compile newer versions of m4 and bison
At least I now have an up and running postgres server
Thanks for all the help
Mark Campbell
Confidentiality Notice: http://ucs.co.za/conf.html
How do you hope to avoid this overhead when you're looking to track
information on every single SELECT statement? Or were you looking to
only log access to some specific tables?
On Mon, May 15, 2006 at 09:38:54AM -0500, Hogan, James F. Jr. wrote:
Thank you all for the effort you put into
Martijn van Oosterhout kleptog@svana.org writes:
All you need to do is decide where you are going to store the level
number and add it as a system attribute (negative attribute number).
This could only work if LEVEL is guaranteed to have one and only one
value per tuple. I'm not too sure about
On 5/15/06, Tom Lane [EMAIL PROTECTED] wrote:
This could only work if LEVEL is guaranteed to have one and only one
value per tuple. I'm not too sure about the spec but it seems like
that'd probably fall down in join situations.
Yes, this was another thing handled by Evgen's patch... FakeVar
Only specific tables.
Of the 150 plus existing there are only 8 or 10 that hold sensitive
data.
This will grow over time but will always be in the minority.
-Original Message-
From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
Sent: Monday, May 15, 2006 10:42 AM
To: Hogan, James F. Jr.
On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
Only specific tables.
Of the 150 plus existing there are only 8 or 10 that hold sensitive
data.
In that case I'd definately go with the suggestion of creating access
functions and logging to a table from within them. Just
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
Only specific tables.
Of the 150 plus existing there are only 8 or 10 that hold sensitive
data.
In that case I'd definately go with the suggestion of creating access
functions and
A recent post Tom made in -bugs about how bad performance would be if we
spilled after-commit triggers to disk got me thinking... There are
several operations the database performs that potentially spill to disk.
Given that any time that happens we end up caring much less about CPU
usage and much
Moving to -hackers
On Wed, May 10, 2006 at 11:26:30AM -0300, Cristiano Duarte wrote:
Don't know whether this would help in your situation, but you can make the
output of EXPLAIN disambiguous by using table aliases:
EXPLAIN
SELECT *
FROM schema1.mytable AS mt1, schema2.mytable AS
On Wed, May 10, 2006 at 08:46:41PM +0200, Zdenek Kotala wrote:
I would like to implement following item from TODO list:
* Allow commenting of variables in postgresql.conf to restore them to
defaults. Currently, if a variable is commented out, it keeps the
previous uncommented value until a
Jim C. Nasby [EMAIL PROTECTED] writes:
A recent post Tom made in -bugs about how bad performance would be if we
spilled after-commit triggers to disk got me thinking... There are
several operations the database performs that potentially spill to disk.
Given that any time that happens we end up
On Mon, May 15, 2006 at 12:37:34PM -0400, Douglas McNaught wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
Only specific tables.
Of the 150 plus existing there are only 8 or 10 that hold sensitive
data.
In that
On Mon, May 15, 2006 at 02:18:03PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
A recent post Tom made in -bugs about how bad performance would be if we
spilled after-commit triggers to disk got me thinking... There are
several operations the database performs that
Jim C. Nasby wrote:
On Mon, May 15, 2006 at 02:18:03PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
A recent post Tom made in -bugs about how bad performance would be if we
spilled after-commit triggers to disk got me thinking... There are
several operations the
On Mon, May 15, 2006 at 03:44:50PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
On Mon, May 15, 2006 at 02:18:03PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
A recent post Tom made in -bugs about how bad performance would be if we
spilled after-commit triggers
On Mon, May 15, 2006 at 03:02:07PM -0500, Jim C. Nasby wrote:
The problem is that it seems like there's never enough ability to clue
the OS in on what the application is trying to accomplish. For a long
time we didn't have a background writer, because the OS should be able
to flush things out
On Mon, May 15, 2006 at 10:09:47PM +0200, Martijn van Oosterhout wrote:
In this case the problem is that we want to tell the OS Hey, if this
stuff is actually going to go out to the spindles then compress it. And
by the way, we won't be doing any random access on it, either. But
AFAIK
Sorry for cross-posting, but this IS a cross-platform issue.
Christian Tismer tismer at stackless.com wrote:
Sven Suursoho wrote:
Is there any way to rewrite following program to handle returned
generator without hitting this bug?
The only way I can think of getting around this is
Hannu Krosing [EMAIL PROTECTED] writes:
Sven Suursoho wrote:
As for testing in actual pl/python build environment, we had objections
from
leading postgresql Tom Lane that even if we do test it at build time,
a determined DBA may substitute a buggy python.so later and still crash her
DB
Ühel kenal päeval, E, 2006-05-15 kell 17:21, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
Sven Suursoho wrote:
As for testing in actual pl/python build environment, we had objections
from
leading postgresql Tom Lane that even if we do test it at build time,
a determined
Jim C. Nasby wrote:
There's an fadvise that tells the OS to compress the data if it actually
makes it to disk?
Compressed-filesystem extension (like e2compr, and I think either
Fat or NTFS) can do that.
I think the reasons against adding this feature to postgresql are
largely the same as the
Ron Mayer [EMAIL PROTECTED] writes:
I think the real reason Oracle and others practically re-wrote
their own VM-system and filesystems is that at the time it was
important for them to run under Windows98; where it was rather
easy to write better filesystems than your customer's OS was
bundled
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
I think the real reason Oracle and others practically re-wrote
their own VM-system and filesystems is that at the time it was
important for them to run under Windows98; where it was rather
easy to write better filesystems than your customer's
Hi,
inpostgresql-8.1.3/src/backend/storage/lmgr/proc.c
there are 2 function InitProcess and
InitDummyProcess, both use
" if (MyProc != NULL) elog(ERROR,
"you already exist"); " (line 215 and 315)
why use " != " ?
Best regards.
Having tinkered a little with PQA, yes, actually. The issue is that the
message text can easily be multi-line and contain a vast variety of
special characters. The issue is figuring out where the prefix, the tag
and the message begin and end. And our text log format makes that a PITA.
Try
Hello,
I was dinking around wand came across something that may (or may not be
useful).
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
E.g;
postgres=# select * from foo; update foo set bar = 'baz'; delete from bing;
Would be a
Joshua D. Drake [EMAIL PROTECTED] writes:
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
regards, tom lane
---(end of
Joshua D. Drake [EMAIL PROTECTED] wrote
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
E.g;
postgres=# select * from foo; update foo set bar = 'baz'; delete from
bing;
Would be a single transaction ? The begin/commit would be
ipig [EMAIL PROTECTED] wrote
in postgresql-8.1.3/src/backend/storage/lmgr/proc.c
there are 2 function InitProcess and InitDummyProcess, both use
if (MyProc != NULL)
elog(ERROR, you already exist); (line 215 and 315)
why use != ?
I guess you misread exist to exit? Try
It done so, because InitProcess() is supposed to be called only
once per backend, because it allocates a PGPROC from a LIST OF free
PGPROCs.
So with this test, and calling elog( ERROR, ... ) we are stopping
the caller from doing a second initialization for this backend.
On 5/16/06, ipig
On Mon, May 15, 2006 at 05:42:53PM -0700, Joshua D. Drake wrote:
Windows98? No, those decisions predate any thought of running Oracle
on Windows, probably by decades. But I think the thought process was
about as above whenever they did make it; they were running on some
pretty stupid OSes
I don't think Cristiano is asking for the schema_name in the
EXPLAIN o/p. The request is for the table ALIASes to be shown in the
o/p, which makes more sense than schema_name+table_name, since the
same table can be used in the same query more than once.
Gurjeet.
On 5/15/06, Jim C. Nasby
Gurjeet Singh [EMAIL PROTECTED] writes:
I don't think Cristiano is asking for the schema_name in the
EXPLAIN o/p. The request is for the table ALIASes to be shown in the
o/p, which makes more sense than schema_name+table_name, since the
same table can be used in the same query more than
Oh come on, Sorry to troll but this is too easy.
On 5/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You guys have to kill your Windows hate - in jest or otherwise. It's
zealous, and blinding.
[snip]
Why would it
be assumed, that a file system designed for use from a desktop, would be
[EMAIL PROTECTED] wrote:
The real question - and I believe Tom and others have correctly harped
on it in the past is - is it worth it? Until somebody actually pulls
up their sleeves, invests a month or more of their life to it, and
does it, we really won't know. And even then, the cost of
As Qingqing Zhou said, i misread exist.
Thanks.
- Original Message -
From: Gurjeet Singh [EMAIL PROTECTED]
To: ipig [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Tuesday, May 16, 2006 11:36 AM
Subject: Re: [HACKERS] Why use !=
It done so, because InitProcess() is
Jonah H. Harris [EMAIL PROTECTED] writes:
I'm reworking hierarchical queries and am adding a LEVEL pseudocolumn.
As it's a totally calculated attribute, what's the best way to handle
it keeping in mind that LEVEL is only used in a hierarchical query?
Perhaps you should start by explaining
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
I wouldn't assume that it would be a default feature of course. Perhaps
On May 16, 2006, at 13:42 , Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What if single line statements that were seperated by ; within
psql were implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
I wouldn't assume
Michael Glaesemann [EMAIL PROTECTED] writes:
What use case are you envisioning? Just saving ... *counts ... 14
keystrokes in this case? (I'm not saying there *isn't* a use case. I
just don't see a big benefit here.)
Quite aside from the compatibility and how-useful-is-it-really
arguments,
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
What use case are you envisioning? Just saving ... *counts ... 14
keystrokes in this case? (I'm not saying there *isn't* a use case. I
just don't see a big benefit here.)
Quite aside from the compatibility and
Tom Lane wrote:
Quite aside from the compatibility and how-useful-is-it-really
arguments, I think this'd be a bad idea in the abstract. SQL is not one
of those languages that assigns semantic significance to the shape of
whitespace [1]. We should NOT introduce any such concept into psql,
47 matches
Mail list logo
