On Sun, Mar 09, 2008 at 10:45:59PM +0100, Dawid Kuroczko wrote:
> > alter table tab add column col integer not null default 42 check (col > 0);
>
> I think this will not solve the OP's problem. He wants to minimize the time
> a table is under exclusive lock, and this ALTER command will effective
Am Freitag, 7. März 2008 schrieb Tom Lane:
> I'm not wedded to the number 1000 in particular --- obviously that's
> just a round number. But it would be good to see some performance tests
> with larger settings before deciding that we don't need a limit.
Well, I'm not saying we should raise the d
On Sun, 2008-03-09 at 23:03 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I've coded a small patch to allow CaseSensitive synonyms.
>
> Applied with corrections (it'd be good if you at least pretended to test
> stuff before submitting it).
It is a frequent accusation of you
Le Monday 10 March 2008, Peter Eisentraut a écrit :
> Am Freitag, 7. März 2008 schrieb Tom Lane:
> > I'm not wedded to the number 1000 in particular --- obviously that's
> > just a round number. But it would be good to see some performance tests
> > with larger settings before deciding that we don
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You yourself encourage a group
development approach and specifically punish those people droppi
On Mon, Mar 10, 2008 at 11:36 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> The time to analyze is also quite constant, just before you run out of
> memory. :) The MaxAllocSize is the limiting factor in all this. In my
> example, statistics targets larger than about 80 created pg_stati
Hello,
Let me try again...
Here is simple example.
To do:
alter table users add column integer not null default 0;
Table is big, updated, referenced etc (big - means that alter lock the
table long enought
to kill the system). Note that it is not my design - I have to do
alter the table... b
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 7. März 2008 schrieb Tom Lane:
>> IIRC, egjoinsel is one of the weak spots, so tests involving planning of
>> joins between two tables with large MCV lists would be a good place to
>> start.
> I have run tests with joining two and three ta
On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> > As Greg mentions on another thread, not all patches are *intended* to be
> > production quality by their authors. Many patches are shared for the
> > purpose of eliciting general feedback. You yourself encourage a
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Am Freitag, 7. März 2008 schrieb Tom Lane:
>>> IIRC, egjoinsel is one of the weak spots, so tests involving planning of
>>> joins between two tables with large MCV lists would be a good place to
>>> start.
>
>
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think if you post something marked Work In Progress, there is an
> implied commitment on your part to post something complete at a later stage.
It *wasn't* marked Work In Progress, and Simon went out of his way to
cross-post it to -patches, where the
On Mon, 2008-03-10 at 09:42 -0400, Andrew Dunstan wrote:
> I think if you post something marked Work In Progress, there is an
> implied commitment on your part to post something complete at a later stage.
>
> So if it's forgotten you would be the one doing the forgetting. ;-)
But if they aren't
Simon Riggs wrote:
On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You yours
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Sun, 9 Mar 2008, Tom Lane wrote:
>> Would a similar parameter be useful for any of the other dictionary
>> types?
> There are many things desirable to do with dictionaries, for example,
> say dictionary to return an original word plus it's normal form
On Mon, 2008-03-10 at 10:01 -0400, Tom Lane wrote:
> In future perhaps I should take it as a given that
> Simon doesn't expect his patches to be applied?
I think you should take it as a given that Simon would like to try to
work together, sharing ideas and code, without insults and public
derisio
Andrew Dunstan wrote:
>
>
> Simon Riggs wrote:
> > As Greg mentions on another thread, not all patches are *intended* to be
> > production quality by their authors. Many patches are shared for the
> > purpose of eliciting general feedback. You yourself encourage a group
> > development approach a
Hmm, I can see how some middleware would help with folding or not
folding the input token, but what about the words coming from the
dictionary file (particularly the *output* lexeme)? It's not apparent
to me that it's sensible to try to control that from outside the
dictionary.
Right now I see
Well, if you think this can/should be done somewhere outside the
dictionary, should I revert the applied patch?
No, that patch is about case sensitivity of synonym dictionary. I suppose, Simon
wants to replace 'bill' to 'account', but doesn't want to get 'account Clinton'
For another dictiona
Kris Jurka <[EMAIL PROTECTED]> writes:
> Gcc 4.3 has started to perform optimizations based on the denial of the
> existence of signed overflow.
> ...
> I don't understand the difference between -fwrapv and
> -fno-strict-aliasing, but it seems we need at least one of them.
I don't see -fno-stric
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Hmm, I can see how some middleware would help with folding or not
>> folding the input token, but what about the words coming from the
>> dictionary file (particularly the *output* lexeme)? It's not apparent
>> to me that it's sensible to try to control
Right now I see an significant advantage of such layer: two possible
extension of dictionary (filtering and storing original form) are
One more extension: drop too long words. For example, decrease limit of max
length of word to prevent long to be indexed - word with 100 characters is
suspic
Hi,
what's your opinion on this?
I saw response only from Alvaro on the -patches list.
Thanks in advance,
Zoltán Böszörményi
Eredeti üzenet
Tárgy: Re: [PATCHES] 64-bit CommandIds
Dátum: Tue, 04 Mar 2008 21:52:25 +0100
Feladó: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Cí
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> Hi,
>
> what's your opinion on this?
> I saw response only from Alvaro on the -patches list.
I don't understand. The patch only affects configuration and SQL data type
code. It doesn't actually store the 64-bit commandid anywhere which would be
I'm reviewing this patch
http://archives.postgresql.org/pgsql-patches/2007-04/msg00531.php
which contains this configure.in code to decide if it's safe to allow
use of non-segmented files:
if test $ac_cv_func_fseeko = yes; then
AC_SYS_LARGEFILE
fi
+ if test "$ac_cv_sys_large_files" = "no"
Gregory Stark wrote:
I don't understand. The patch only affects configuration and SQL data type
code. It doesn't actually store the 64-bit commandid anywhere which would be
the actual hard part.
Sure it does, this is the significant part of the patch:
*** pgsql.orig/src/include/c.h 2008-03-02
Bruce Momjian wrote:
> I have an idea for this TODO item:
>
> * Allow administrators to safely terminate individual sessions either
> via an SQL function or SIGTERM
>
> Lock table corruption following SIGTERM of an individual backend
> has been reported in 8.0.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> When we get the termination signal, why can't we just set a global
>> boolean, do a query cancel, and in the setjmp() code block check the
>> global and exit --- at that stage we know we have released all locks and
>> can exit clea
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> When we get the termination signal, why can't we just set a global
> >> boolean, do a query cancel, and in the setjmp() code block check the
> >> global and exit --- at that stage we know we have released all
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> When we get the termination signal, why can't we just set a global
> >> boolean, do a query cancel, and in the setjmp() code block check the
> >> global and exit --- at that stage we know we have released all
Am Montag, 10. März 2008 schrieb Gregory Stark:
> > It's not possible to believe that you'd not notice O(N^2) behavior for N
> > approaching 80 ;-). Perhaps your join columns were unique keys, and
> > thus didn't have any most-common-values?
>
> We could remove the hard limit on statistics tar
Am Montag, 10. März 2008 schrieb Tom Lane:
> A quick look at the configure script suggests that the available macros
> don't really set anything that specifically tells you if they found
> working largefile support. I'm considering doing AC_CHECK_SIZEOF(off_t)
> and then looking at the result
Tha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am suggesting we add a new fuction pg_terminate_backend() that does
> everything just like cancel, but also sets a global variable that we
> check in the loop where we look for the next command and if it is set,
> we exit the backend.
And if you never
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am suggesting we add a new fuction pg_terminate_backend() that does
> > everything just like cancel, but also sets a global variable that we
> > check in the loop where we look for the next command and if it is set,
> > we exit the b
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Keep in mind that 99% of the excuse for people to want to use SIGTERM is
>> that the backend isn't responding to SIGINT. If you've fixed things so
>> that SIGTERM cannot get them out of any situation that SIGINT doesn't
>> get them out
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> There is latest version of nonsegment support patch. I changed
> LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
> -disable-segmented-files switch to configure. I kept tuplestore behavior
> and it still split file in both mode.
Applied with
> We could remove the hard limit on statistics target and
> impose the limit
> instead on the actual size of the arrays. Ie, allow people to
> specify larger
> sample sizes and discard unreasonably large excess data
> (possibly warning them
> when that happens).
>
> That would remove the screw
Tom Lane wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > There is latest version of nonsegment support patch. I changed
> > LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
> > -disable-segmented-files switch to configure. I kept tuplestore behavior
> > and it still split file in bo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Applied with minor corrections.
> Why is this not the default when supported?
Fear.
Maybe eventually, but right now I think it's too risky.
One point that I already found out the hard way is that sizeof(off_t) = 8
does not guaran
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > > There is latest version of nonsegment support patch. I changed
> > > LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
> > > -disable-segmented-files switch to configure. I kept tuplestore behavior
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
It's certainly not sensical for these actions to affect the backend that
actually executes the COMMIT PREPARED, in the sense of creating or
destroying pg_listener entries for it. But how can we say that they
should affe
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Also it would get more buildfarm coverage if it were default. If it
> breaks something we'll notice earlier.
Since nothing the regression tests do even approach 1GB, the odds that
the buildfarm will notice problems are approximately zero.
Tom Lane wrote:
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
...
Comments?
Assuming I understand your question - I don't think of LISTEN or
UNLISTEN as being valuable from a transaction perspective. It's possible
I'm missing something - but I think the tra
Mark Mielke <[EMAIL PROTECTED]> writes:
> ... I think the transaction overhead, and
> attempts to re-use PostgreSQL tables to implement LISTEN/NOTIFY to be
> clever but mis-guided.
Oh, I don't disagree with you. As I already mentioned, they desperately
need to be rewritten. However, given that
Tom Lane wrote:
Mark Mielke <[EMAIL PROTECTED]> writes:
... I think the transaction overhead, and
attempts to re-use PostgreSQL tables to implement LISTEN/NOTIFY to be
clever but mis-guided.
Oh, I don't disagree with you. As I already mentioned, they desperately
need to be rewritten.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Keep in mind that 99% of the excuse for people to want to use SIGTERM is
> >> that the backend isn't responding to SIGINT. If you've fixed things so
> >> that SIGTERM cannot get them out of any situation that SIGI
45 matches
Mail list logo
