-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
>
> I'm inclined to think that the concept of force_input_size is wrong.
> Instead I suggest that we have a min_comp_rate (minimum percentage
> savings) and a min_savings (minimum absolute savings), and compress
> if either one is met.
Greg complained here
http://archives.postgresql.org/pgsql-patches/2007-07/msg00342.php
that the default strategy parameters used by the TOAST compressor
might need some adjustment. After thinking about it a little I wonder
whether they're not even more broken than that. The present behavior
is:
Gregory Stark <[EMAIL PROTECTED]> writes:
> Testers here were having a hard time constructing test cases to reach some
> lines touched by the varvarlena patch. Upon further investigation I'm
> convinced they're unreachable.
I'm not really happy with any of this patch. ISTM that the stuff you
say
Decibel! <[EMAIL PROTECTED]> writes:
> Perhaps if we don't have log_timezone set yet we could output something
> such as 'LOCALTIME' so that it was obvious. Or maybe output whatever $TZ
> is set to?
I think you're confused. This is not a matter of knowing what to print
for the timezone part, it's
Comparing with MySQL/FireBird is not to be taken other-wise. Good things
need to be taken care of if they can benefit users. Yes, it is open source
and one can contribute code. But the level of expertise and skill also
matters. PGSQL development community involve experts in the areas of RDBMS,
C/C+
Neil Conway wrote:
On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
So what are *you* doing about it? This is open source, where if you want
it and it's not there you make it. Otherwise you're just one more
whinger wanting something for nothing.
I don't agree with this attit
On Sat, Aug 04, 2007 at 12:46:32PM -0400, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > Something else to consider... normally you'd have to have a pretty
> > serious condition to run into this in normal usage, right? (I doubt
> > there's many folks that use any debug level, let alone
Decibel! <[EMAIL PROTECTED]> writes:
> Something else to consider... normally you'd have to have a pretty
> serious condition to run into this in normal usage, right? (I doubt
> there's many folks that use any debug level, let alone 3) I think that
> gives us more flexibility.
Yeah. This whole is
On Sat, Aug 04, 2007 at 12:12:46PM -0400, Tom Lane wrote:
> There's a value judgment involved here: is it better to print timestamps
> in GMT (which the user won't be expecting) than to not print them at all?
> I can see arguments on both sides of that.
As long as it's clear that the times are in
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Any way to tweak this place and have it log in GMT instead, when
> log_timezone is NULL?
I think this is just a variant of my #2. The main risk factor IMHO
is that the first call is going to invoke tzload() for the GMT zone
(pgtz does not seem to spec
On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
> So what are *you* doing about it? This is open source, where if you want
> it and it's not there you make it. Otherwise you're just one more
> whinger wanting something for nothing.
I don't agree with this attitude at all: we should be l
Tom Lane wrote:
> I came across a problem with the log_timezone patch. Given these
> conditions:
> * log_min_messages is at least debug3
> * log_line_prefix includes %t or %m
> * log_timezone is not explicitly set in postgresql.conf
> the postmaster will dump core during startup, because it tries
I came across a problem with the log_timezone patch. Given these
conditions:
* log_min_messages is at least debug3
* log_line_prefix includes %t or %m
* log_timezone is not explicitly set in postgresql.conf
the postmaster will dump core during startup, because it tries to format
an elog message us
> --- Original Message ---
> From: "Rohit Khare" <[EMAIL PROTECTED]>
> To: "Dave Page" <[EMAIL PROTECTED]>
> Sent: 04/08/07, 12:58:25
> Subject: Re: [HACKERS] .NET driver
>
> Seeing the history of PostgreSQL development, following features are
> expected in pgAdmin:
I don't see what any
Rohit Khare wrote:
> Seeing the history of PostgreSQL development, following features are
> expected in pgAdmin:
>
> (1) Facility to insert a column in between other columns during table
> design.
This I can see how people like, actually. Theorists claim it's not
needed since column order really
Rohit Khare wrote:
I once discussed with you all regarding Oracle's FlashBack Query feature
to recover a database to a certain point of time. That time you all
suggested some indepth cons of this and how it is resource hungry.
One more feature that I am not sure PostgreSQL has is, row-level,
Rohit Khare wrote:
Seeing the history of PostgreSQL development, following features are
expected in pgAdmin:
(1) Facility to insert a column in between other columns during table
design.
(2) Facility to view relationship diagram.
(3) Facility to view table performance level graphically.
(4)
On Aug 4, 2007, at 7:06 , Rohit Khare wrote:
One more feature that I am not sure PostgreSQL has is, row-level,
column-level security. Oracle call this Label-Security in which you
define a policy for certain columns so that they are not visible to
un-authorised users during SELECT queries.
Rohit Khare wrote:
> One more feature that I am not sure PostgreSQL has is, row-level,
> column-level security. Oracle call this Label-Security in which you
> define a policy for certain columns so that they are not visible to
> un-authorised users during SELECT queries. This is an important
> secu
I once discussed with you all regarding Oracle's FlashBack Query feature to
recover a database to a certain point of time. That time you all suggested
some indepth cons of this and how it is resource hungry.
One more feature that I am not sure PostgreSQL has is, row-level,
column-level security. O
Seeing the history of PostgreSQL development, following features are
expected in pgAdmin:
(1) Facility to insert a column in between other columns during table
design.
(2) Facility to view relationship diagram.
(3) Facility to view table performance level graphically.
(4) More documented interface
Rohit Khare wrote:
PostgreSQL has the oldest community of coders, and PostgreSQL itself is
the oldest product. Still its performance (in some areas) and GUI does
not match MySQL. MySQL .NET Driver gives very good performance for the
MySQL Database, FireBird .NET Driver gives performance for Fir
On Fri, 2007-08-03 at 18:16 -0400, Tom Lane wrote:
> In any case this is getting pretty darn far away from a one-liner patch.
> I think it needs more thought and more testing than we can spare now.
Agreed.
We're much further behind with this release than ever before, so we need
to put the cut so
23 matches
Mail list logo
