On 2/5/06, Neil Conway [EMAIL PROTECTED] wrote:
If you're referring to the raw parser (parser/gram.y), you should not
attempt to access any tables. For one thing, the raw parser might be
invoked outside a transaction. The statement might also refer to a table
created earlier in the same query
Hello,
I know so db 500 000 users isn't normal situation, but I need it. After
user's generation all selects on system's catalog are slow. For example:
list of sequences
SELECT n.nspname as Schema,
c.relname as Name,
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN
On Mon, 2006-01-30 at 17:19 -0500, Bruce Momjian wrote:
Ted Powell wrote:
On Mon, Jan 30, 2006 at 04:31:29PM -0500, Bruce Momjian wrote:
I assume it is this TODO:
* Allow protocol-level BIND parameter values to be logged
Simon,
For me the usage pattern would be: log all params, bind time values, on
the same log line as log_min_duration entries. That's what I need to
know which are the non-performant queries, and it also helps on
occasions to identify application problems.
In any case all your plans sound very
adey [EMAIL PROTECTED] writes:
Please let me know if there is a way to determine when the Postmaster was
last restarted?
The last postmaster start time, or the last database reset? These are
not the same if any backends have crashed since the postmaster started.
For determining stats lifespan
On Mon February 6 2006 05:17, Mark Woodward wrote:
I posted some source to a shared memory sort of thing to the group, as
well as to you, I believe.
Indeed, and it looks rather interesting. I'll have a look through it
when I
have a chance...
So, after more discussion and
Pavel Stehule wrote:
I know so db 500 000 users isn't normal situation, but I need it.
After user's generation all selects on system's catalog are slow. For
example: list of sequences
SELECT n.nspname as Schema,
c.relname as Name,
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN
On 2006-02-06, Peter Eisentraut [EMAIL PROTECTED] wrote:
I suggest that your problem is the join order (unless you have 50
tables as well). Moreover, using left joins instead of inner joins
seems to be quite useless unless you plan to have tables that are not
owned by anyone and are
On Mon February 6 2006 05:17, Mark Woodward wrote:
I posted some source to a shared memory sort of thing to the group, as
well as to you, I believe.
Indeed, and it looks rather interesting. I'll have a look through it
when
I
have a chance...
So, after more discussion and
Hello Magnus,Regarding the configure issue:The platform is Tru64 Unix 5.1b, the problem I had was we havecompiled our Kerberos build statically and is installed in a directory other than the standard location. The trick adding to LIBS
did not work as it (krb5support) library needs to come after
Hello Magnus,
Regarding the configure issue:
The platform is Tru64 Unix 5.1b, the problem I had was we
have compiled our Kerberos build statically and is installed
in a directory other than the standard location. The trick
adding to LIBS did not work as it (krb5support) library needs
Thanks.As far as using TLS, it is good approach. Although, we don't need complete channel encryption for every transaction or query. I am looking at a more granular approach whereI can decide depending on the security of information exchange whether to encrypt the
channel or not (like using maybe
Mohan K wrote:
Regarding the configure issue:
The platform is Tru64 Unix 5.1b, the problem I had was we have
compiled our Kerberos build statically and is installed in a
directory other than the standard location. The trick adding to LIBS
did not work as it (krb5support) library needs to
On Mon, 2006-02-06 at 13:28 +0100, Csaba Nagy wrote:
For me the usage pattern would be: log all params, bind time values, on
the same log line as log_min_duration entries. That's what I need to
know which are the non-performant queries, and it also helps on
occasions to identify application
Andrew - Supernews wrote:
Perhaps you missed the fact that the query was not one that he wrote,
but is the query that psql uses for \ds ?
I did miss that. Perhaps with dependency tracking and all, we don't
need the left joins anymore?
--
Peter Eisentraut
Peter,It is chicken and egg problem, I still need to enable kerberos in the configure script to make sure proper pieces are picked up. But of coursethe configure script fails :).If I provide the relevant patches to
configure.in script is that acceptable?thanksOn 2/6/06, Peter Eisentraut
[EMAIL
On Sun, Feb 05, 2006 at 07:14:49PM -0800, Stephan Szabo wrote:
On Sun, 5 Feb 2006, James William Pye wrote:
However, constraints referenced in an UNLESS clause that are deferred, in
any
fashion, should probably be immediated within the context of the command.
Perhaps a WARNING or NOTICE
Peter Eisentraut [EMAIL PROTECTED] writes:
Andrew - Supernews wrote:
Perhaps you missed the fact that the query was not one that he wrote,
but is the query that psql uses for \ds ?
I did miss that. Perhaps with dependency tracking and all, we don't
need the left joins anymore?
I don't see
James,
Are you sure that a new type of constraint is the way to go for this?
It doesn't solve our issues in the data warehousing space. The spec we
started with for Error-tolerant COPY is:
1) It must be able to handle parsing errors (i.e. bad char set);
2) It must be able to handle
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2006-02-06, Peter Eisentraut [EMAIL PROTECTED] wrote:
It already has indexes.
True, but they're not being used where you'd expect. This seems to be
something to do with the fact that it's not pg_authid which is being
accessed, but rather the
On Mon, 6 Feb 2006, Josh Berkus wrote:
Are you sure that a new type of constraint is the way to go for this?
It doesn't solve our issues in the data warehousing space. The spec we
started with for Error-tolerant COPY is:
1) It must be able to handle parsing errors (i.e. bad char set);
2)
On Mon, 6 Feb 2006, James William Pye wrote:
On Sun, Feb 05, 2006 at 07:14:49PM -0800, Stephan Szabo wrote:
On Sun, 5 Feb 2006, James William Pye wrote:
However, constraints referenced in an UNLESS clause that are deferred, in
any
fashion, should probably be immediated within the
kleptog@svana.org (Martijn van Oosterhout) writes:
On Sat, Feb 04, 2006 at 01:54:52AM +0100, Peter Eisentraut wrote:
I took a first swing at this and rearranged some of these calls.
ld -- On AIX at least this seems to be some magic library but doesn't
have an obvious testable symbol.
Alon Goldshuv on Bizgres has been working on this as well. Maybe you
could collaborate? Alon?
I would love to collaborate. The proposal is neat, however, I am not too
excited about handling errors in such high granularity, as far as the user
is concerned. I am more on the same line with Tom
On Mon, Feb 06, 2006 at 11:03:06AM -0800, Josh Berkus wrote:
Are you sure that a new type of constraint is the way to go for this?
[Thinking that you are referring to the new constraint mode that I was
confusingly referring to...]
Well, it really wouldn't be new. It's just labeling what we do
James,
The difficulty of my implementation comes from the position that I don't
think the current implementation of UNIQUE constraints is ideal. It is
hidden inside nbtree, which, while convenient, is not likely to be the
best place for it.
Agreed; one of the things that's been on the TODO
Hi,
There is something wrong with createlang on my
windows system. Please, see the output:
C:\Arquivos de
programas\PostgreSQL\8.1\bin\createlang.exe pltcl -U postgres
test
createlang: language installation failed:
ERROR: could not load library C:/Arq
uivos de
On Fri, 2006-02-03 at 22:29 -0500, Bruce Momjian wrote:
Based on this, I think we should just implement the TRUNCATE/DROP option
for the table, and avoid the idea of allowing non-logged operations on a
table that has any data we want recovered after a crash.
Well the only other option is
Do you have tcl installed on your machine? You need it, and it probably
needs to be in your path, if you want to use pltcl.
This is not a -hackers question, btw - you should ask this somewhere
like -general.
cheers
andrew
Márcio A. Sepp wrote:
Hi,
There is something wrong with
Mohan K wrote:
Peter,
It is chicken and egg problem, I still need to enable kerberos in the
configure script to make sure proper pieces are picked up. But of course
the configure script fails :).
If I provide the relevant patches to configure.in script is that acceptable?
thanks
Probably if
I have split up the TODO items as:
* Allow WAL logging to be turned off for a table, but the table
might be dropped or truncated during crash recovery [walcontrol]
Allow tables to bypass WAL writes and just fsync() dirty pages on
commit.
* Allow WAL logging to be turned off for a table, but the table
might be dropped or truncated during crash recovery [walcontrol]
Allow tables to bypass WAL writes and just fsync() dirty pages on
commit. This should be implemented using ALTER TABLE,
Bruce Momjian pgman@candle.pha.pa.us writes:
TABLE PERSISTENCE [ DROP | TRUNCATE | DEFAULT ]. Tables using
non-default logging should not use referential integrity with
default-logging tables.
I have to say this smells way too much like MySQL for me to feel
I was thinking the exact same thing. Except the and just fsync()
dirty pages on commit part. Wouldn't that actually make the
situation worse? I thought the whole point of WAL was that it was
more efficient to fsync all of the changes in one sequential write in
one file rather than
Rick Gigger wrote:
I was thinking the exact same thing. Except the and just fsync()
dirty pages on commit part. Wouldn't that actually make the
situation worse? I thought the whole point of WAL was that it was
more efficient to fsync all of the changes in one sequential write in
On Mon, Feb 06, 2006 at 04:45:11PM -0500, Chris Browne wrote:
Further, it appears to be AIX pre-4.3 only, when using it for dlopen()
replacement...
It would be an attractive idea to have configure detect not whether
it's open, but rather whether it is needed, and leave it out for AIX
4.3
In the meantime, reducing the LEFT JOIN to pg_roles to a JOIN as per
Peter's suggestion seems like the best short-term workaround.
It's solution
explain analyze SELECT n.nspname as Schema,
c.relname as Name,
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN
'index'
Rick Gigger wrote:
I was thinking the exact same thing. Except the and just fsync()
dirty pages on commit part. Wouldn't that actually make the
situation worse? I thought the whole point of WAL was that it was
more efficient to fsync all of the changes in one sequential write in
one file
38 matches
Mail list logo
