Jim Nasby writes:
> [ add some error ranges to cost estimates ]
> I believe that would fix this specific case because even though to plans
> might come out with a nearly identical cost it is unlikely that they would
> also have a nearly identical error range.
Actually, I think that *wouldn't*
On 19 April 2012 19:24, Dimitri Fontaine wrote:
> I kind of understood timsort would shine in sorting text in non-C
> collation, because of the comparison cost. So a test in some UTF8
> collation or other would be interesting, right?
That's certainly the theory, yes. In practice, even though tims
On 4/19/12 5:39 PM, Tom Lane wrote:
Now, neither of these fixes is perfect: what they would do is remove
platform-specific instability from where the costs are basically equal
and add some more in the range where the costs differ by almost exactly
the fuzz factor. But the behavior near that poin
So after committing the latest round of parameterized-plan hacking,
I was dismayed to see the buildfarm breaking out in pink, thanks to
some of the members producing a different plan than expected for one
test query. I eventually managed to reproduce that (on the fourth
machine I tried locally), a
Alvaro Herrera writes:
> Remember that we're talking about REASSIGN OWNED here, which will
> automatically reassign not only the extension itself, but also the
> contained objects. There is no danger that we will end up with an
> inconsistent installation. Also, if the objects in the extension h
Excerpts from Dimitri Fontaine's message of jue abr 19 12:42:00 -0300 2012:
> What about only issuing a WARNING that the extensions are not supported
> by reassign owned in 9.1 (and probably 9.2)?
Raise a warning and then do what? While you can continue reassigning
the rest of the objects to so
Peter Eisentraut writes:
> On tor, 2012-04-19 at 00:13 +0300, Alex wrote:
>> +#!/usr/bin/env perl
>
> Don't do that. Call the script using $(PERL) from the makefile.
Thank you for the suggestion. Attached v2 does just this (while keeping
a more commonly found shebang line in the perl script fo
On 4/19/12 5:42 AM, Gianni Ciolli wrote:
currently an EXTENSION can mark some of its tables as "configuration
tables" using pg_catalog.pg_extension_config_dump(), so that pg_dump
"does the right thing".
I think it would be useful to mark sequences too, but unfortunately it
is not possible; hence
On 04/19/2012 03:05 PM, Tom Lane wrote:
Andrew Dunstan writes:
At any rate, I found that my spam went to nil by turning off
notifications for comments on my commits and comments that mention me.
The first part of that seems like it would destroy most of the point
of having the mechanism at a
Andrew Dunstan writes:
> At any rate, I found that my spam went to nil by turning off
> notifications for comments on my commits and comments that mention me.
The first part of that seems like it would destroy most of the point
of having the mechanism at all?
regards, to
On 4/19/12, Jeff Janes wrote:
> The work around would be for the master to refuse to automatically
> restart after a crash, insisting on a fail-over instead (or a manual
> forcing of recovery)?
I suppose that would work, but I think Simon's idea is better: don't
let the slave replay the WAL until
On tor, 2012-04-19 at 00:13 +0300, Alex wrote:
> +#!/usr/bin/env perl
Don't do that. Call the script using $(PERL) from the makefile.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Geoghegan writes:
> 1. What we should be doing with timsort, if anything. It is one
> thing to demonstrate that it's a useful algorithm under certain
> artificial conditions, but quite another to argue for its inclusion in
> Postgres, or for it being selectively used at points where that i
On 04/19/2012 11:25 AM, Christopher Browne wrote:
The vast majority of the spam I have originates in the postgresql git
repository. You don't have any commits there...
But I would've assumed it should hit equally hard on other
repositories that's been around a long time.
I have plenty of com
On Thu, Apr 19, 2012 at 2:47 AM, Robert Haas wrote:
> On Apr 19, 2012, at 5:05 AM, Magnus Hagander wrote:
>> I admit to not having followed the discussion around the new mode for
>> synchronous_commit very closely, so my apologies if this has been
>> discussed and dismiseed - I blame failing to f
Hi,
Robert Haas writes:
> On Wed, Apr 18, 2012 at 7:54 PM, Tom Lane wrote:
>> However, ignoring that issue for the moment, this patch is making me
>> uncomfortable. I have a vague recollection that we deliberately omitted
>> ALTER EXTENSION OWNER because of security or definitional worries.
>>
On Thu, Apr 19, 2012 at 10:49 AM, Magnus Hagander wrote:
> On Thu, Apr 19, 2012 at 16:45, Greg Sabino Mullane wrote:
>>
My github.com account currently has 4264 notifications in the inbox.
Almost all of those are spam, growing constantly. �Because of that, the
platform is current
On Thu, Apr 19, 2012 at 16:45, Greg Sabino Mullane wrote:
>
>>> My github.com account currently has 4264 notifications in the inbox.
>>> Almost all of those are spam, growing constantly. �Because of that, the
>>> platform is currently fairly useless to me for actually communicating or
>>> collab
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> My github.com account currently has 4264 notifications in the inbox.
>> Almost all of those are spam, growing constantly. �Because of that, the
>> platform is currently fairly useless to me for actually communicating or
>> collaborating
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> So I think Greg has exactly the right idea: we shouldn't try to
> incorporate one of these systems that aims to manage workflow; we
> should just design something really simple that tracks what happened
> and lets people who wish to volunte
Excerpts from Tom Lane's message of mié abr 18 03:12:09 -0300 2012:
>
> Magnus Hagander writes:
> > I think this cleraly outlines that we need to remember that there are
> > *two* different patterns that people are trying tosolve with the
> > bugtracker.
>
> Yeah, remember we drifted to this to
On Thu, Apr 19, 2012 at 08:47:51AM -0400, Stephen Frost wrote:
> * Sandro Santilli (s...@keybit.net) wrote:
> > Actually a random sample would really be representative of the data
> > distribution. What the type analyzer gets is a sample and that sample
> > is what the estimator looks at to answer
* Sandro Santilli (s...@keybit.net) wrote:
> Actually a random sample would really be representative of the data
> distribution. What the type analyzer gets is a sample and that sample
> is what the estimator looks at to answer the question:
That might work if all you have is point data, but lines
On 10 April 2012 21:07, Magnus Hagander wrote:
> On Friday, April 6, 2012, Thom Brown wrote:
>>
>> Hi,
>>
>> I've tried out pg_receivexlog and have noticed that when restarting
>> the cluster, pg_receivexlog gets cut off... it doesn't keep waiting.
>> This is surprising as the DBA would have to re
Hi,
currently an EXTENSION can mark some of its tables as "configuration
tables" using pg_catalog.pg_extension_config_dump(), so that pg_dump
"does the right thing".
I think it would be useful to mark sequences too, but unfortunately it
is not possible; hence, each time a dump is reloaded, all th
On Thu, Apr 19, 2012 at 10:05 AM, Magnus Hagander wrote:
> I admit to not having followed the discussion around the new mode for
> synchronous_commit very closely, so my apologies if this has been
> discussed and dismiseed - I blame failing to find it int he archives
> ;)
>
> My understanding from
On Thu, Apr 19, 2012 at 12:40, Simon Riggs wrote:
> On Thu, Apr 19, 2012 at 10:05 AM, Magnus Hagander wrote:
>> I admit to not having followed the discussion around the new mode for
>> synchronous_commit very closely, so my apologies if this has been
>> discussed and dismiseed - I blame failing t
On Apr 19, 2012, at 5:05 AM, Magnus Hagander wrote:
> I admit to not having followed the discussion around the new mode for
> synchronous_commit very closely, so my apologies if this has been
> discussed and dismiseed - I blame failing to find it int he archives
> ;)
>
> My understanding from loo
On Mon, 16 Apr 2012 23:17:25 -0700, Heikki Linnakangas wrote:
> 1. We probably don't want the SQL syntax to be added to the
>grammar. This should be written as an extension, using custom
>functions as the API, instead of extra SQL syntax.
I can't find the discussion about this, have any p
I admit to not having followed the discussion around the new mode for
synchronous_commit very closely, so my apologies if this has been
discussed and dismiseed - I blame failing to find it int he archives
;)
My understanding from looking at the docs is that
synchronous_commit=remote_write will alw
On Wed, 2012-04-18 at 01:21 -0400, Tom Lane wrote:
> It would be a pretty weird implementation of mergejoin that could
> "discard tuples from the middle" of an input stream. Or to be more
> specific, it wouldn't be the mergejoin itself that could do that at all
> --- you'd need the input plan node
On Tue, Apr 17, 2012 at 04:29:52PM -0400, Stephen Frost wrote:
> Josh,
>
> * Josh Berkus (j...@agliodbs.com) wrote:
> > FWIW, the PostGIS folks would *really* love to have a TABLESAMPLE which
> > worked with geographic indexes. This would be tremendously useful for
> > constructing low-resolution
Am 18.04.2012 14:28, schrieb Robert Haas:
So I think Greg has exactly the right idea: we shouldn't try to
incorporate one of these systems that aims to manage workflow; we
should just design something really simple that tracks what happened
and lets people who wish to volunteer to do so help ke
On Thu, Apr 19, 2012 at 7:55 AM, Noah Misch wrote:
> On Mon, Mar 12, 2012 at 10:50:36PM -0400, Tom Lane wrote:
>> There is one more (known) stop-ship problem in SPGiST, which I'd kind of
>> like to get out of the way now before I let my knowledge of that code
>> get swapped out again. This is tha
On Tue, 2012-04-17 at 14:03 -0400, Robert Haas wrote:
> I'm actually not sure these are equivalent formulations. Suppose one
> side has [i,i] where i ranges from 1 to 1000 and the other side
> the exact same thing plus [1,1000]. That one really big range
> will come up second on the right
35 matches
Mail list logo
