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 ra
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
'inde
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
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
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 fsy
Bruce Momjian 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
comfortable. But that's just
* 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, e
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. Thi
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
Probab
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 createla
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 th
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 progra
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
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 n
> 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 L
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.
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" w
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);
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 rath
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 constra
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 d
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
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 P
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
http://developer.postgresql.org/~pe
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 applicat
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
> 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 n
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 th
> 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 discuss
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 a
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'
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 exp
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 lifesp
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
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
> > >
> > >
> > >
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' THE
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 q
38 matches
Mail list logo
