On Tue, Mar 1, 2016 at 2:30 PM, Tom Lane wrote:
> There are a couple of
> regression test cases that change plans for the better, but it's sort of
> accidental. Those cases look like
>
> select d.* from d left join (select * from b group by b.id, b.c_id) s
> on d.a = s.id;
>
> and what happ
On Tue, Mar 1, 2016 at 3:02 PM, Tom Lane wrote:
> Well, my point is that no such path would have been generated if the
> subquery hadn't had an internal reason to consider sorting on b.id.
> The "accidental" part of this is that the subquery's GROUP BY key
> matches what the outer query needs as a
On Sat, Mar 5, 2016 at 12:41 PM, Tomas Vondra
wrote:
> And it was dealt with
Well. Not dealt with yet. I think it's more or less clear how to
tackle it using macros and builtins now but there's a lot of drudgery
work to actually rewrite all the checks. I have the reports from Xi
Wang's tool saved
On Sat, Mar 5, 2016 at 12:59 PM, Greg Stark wrote:
> Well. Not dealt with yet. I think it's more or less clear how to
> tackle it using macros and builtins now but there's a lot of drudgery
> work to actually rewrite all the checks. I have the reports from Xi
> Wang'
On Sat, Mar 5, 2016 at 2:35 PM, Tom Browder wrote:
>> [Removing all the other xposted lists -- don't do that!]
>
> Okay, sorry. I thought since the reply was pg-specific it would cut down
> noise.
I'm sorry I was unclear. I meant, I was removing all the others from
my reply and was saying not t
On Sat, Mar 5, 2016 at 6:09 PM, Tom Lane wrote:
> There might be some other things we could do to provide a fast-path for
> particularly trivial cases. But on the whole I think this plot shows that
> there's no systematic problem, and indeed not really a lot of change at
> all.
Amazing data.
Wh
On Mon, Mar 7, 2016 at 3:37 PM, Robert Haas wrote:
>
> The currently-committed code generates paths where nested loops and
> hash joins get pushed beneath the Gather node, but does not generate
> paths where merge joins have been pushed beneath the Gather node. And
> the reason I didn't try to ge
On Thu, Mar 10, 2016 at 1:40 PM, Tomas Vondra
wrote:
> I was thinking about running some benchmarks on this patch, but the
> thread is pretty huge so I want to make sure I'm not missing something
> and this is indeed the most recent version.
I also ran some preliminary benchmarks just before FOSD
On 12 Mar 2016 10:58 pm, "Tom Lane" wrote:
>
> I wrote:
> > That's confusing because it implies that -fno-common is the default,
> > which it evidently is not. But anyway, my diagnosis is that you're
> > breaking something about the linker's behavior with that switch.
> I shall get rid of the co
On Wed, Mar 30, 2016 at 7:23 AM, Peter Geoghegan wrote:
> Anyway, what I liked about Greg's approach to finding regressions at
> the low end was that when testing, he used the cheapest possible VM
> available on Google's cloud platform. When testing the low end, he had
> low end hardware to go wit
On Mon, Jan 18, 2016 at 5:55 PM, Robert Haas wrote:
> For
> example, suppose that x and y are numeric columns and P(x) is
> length(x::text) == 3. Then you could have 1 in one table and 1.0 in
> the table; they join, but P(x) is true for one and false for the
> other.
Fwiw, ages ago there was so
On Fri, Jan 22, 2016 at 8:26 AM, Tomas Vondra
wrote:
> On 01/22/2016 06:45 AM, Michael Paquier wrote:
>
>> So, I have been playing with a Linux VM with VMware Fusion and on
>> ext4 with data=ordered the renames are getting lost if the root
>> folder is not fsync. By killing-9 the VM I am able to r
On Fri, Jan 22, 2016 at 6:21 PM, Andres Freund wrote:
> On 2016-01-22 08:50:15 -0600, Jim Nasby wrote:
>> I think that's a great way to ensure we shrink the pool of reviewers when
>> someone works on a patch and then it goes nowhere.
>
> True, it really sucks. But what's your counter proposal? Com
On 29 Jan 2016 11:58 pm, "Robert Haas" wrote:
> It
> seems pretty easy to construct cases where this technique regresses,
> and a large percentage of those cases are precisely those where
> replacement selection would have produced a single run, avoiding the
> merge step altogether.
Now that avoi
On 30 Jan 2016 8:27 am, "Greg Stark" wrote:
>
>
> On 29 Jan 2016 11:58 pm, "Robert Haas" wrote:
> > It
> > seems pretty easy to construct cases where this technique regresses,
> > and a large percentage of those cases are precisely those where
On Sun, Feb 7, 2016 at 8:21 PM, Robert Haas wrote:
> On Sun, Feb 7, 2016 at 11:00 AM, Peter Geoghegan wrote:
> > It was my understanding, based on your emphasis on producing only a
> > single run, as well as your recent remarks on this thread about the
> > first run being special, that you are re
The tests worked fine on faster build animals, right? And the clobber
animals are much much slower So it seems perfectly sensible that their
deadlock timeout would just have to be much much higher to have the same
behaviour. I see nothing wrong in just setting deadlock timeout to a minute
or mo
For reasons, I was trying to compile older versions of Postgres and
ran into a strange behaviour where system() worked normally but then
returned -1 with errno set to ECHILD. And surprisingly it looks like
we've seen this behaviour in the past but on a Solaris:
commit 07d4d36aae79cf2ac365e381ed3e7
On Mon, Feb 15, 2016 at 8:43 PM, Jim Nasby wrote:
> On 2/7/16 8:57 PM, Peter Geoghegan wrote:
>>
>> It seems less than ideal that DBAs have to be so
>> conservative in sizing work_mem.
>
>
> +10
I was thinking about this over the past couple weeks. I'm starting to
think the quicksort runs gives
On Tue, Feb 16, 2016 at 12:51 AM, Chapman Flack wrote:
> If the calling process subsequently waits for its
> children, and the process has no unwaited for children that were
> transformed into zombie processes, it will block until all of its
> children terminate, and wait(), wait3(), w
On Wed, Aug 17, 2016 at 4:33 AM, Vince Vielhaber
wrote:
>
> I recently moved a mybb forum away from mysql to postgres. Along the way I
> encountered a couple of things that either didn't seem to be supported or
> I'm just not doing it right.
>
> First, the server this is on is running version 8.
On Wed, Aug 17, 2016 at 4:22 PM, Robert Haas wrote:
> We've supported having joins in a DELETE since PostgreSQL 8.1.
Er, yes. Though he does say he's trying to use the same syntax as select...
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev
wrote:
> Frankly I have much more faith in Tom's idea of using virtual part of the
> catalog for all temporary tables, i.e turning all temporary tables into
> "fast" temporary tables. Instead of introducing a new type of temporary tables
> that
On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane wrote:
> To deal with the infinity/NaN issues, I made cube_in and cube_out rely
> on float8in_internal and float8out_internal, as we recently did for the
> core geometric types. That causes the response to "1e-700" to be an
> out-of-range error rather tha
On Tue, Aug 30, 2016 at 11:12 AM, Heikki Linnakangas wrote:
> While profiling some queries and looking at executor overhead, I realized
> that we're not making much use of TupleTableSlot's ability to hold a buffer
> pin. In a SeqScan, the buffer is held pinned by the underlying heap-scan
> anyway.
On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut
wrote:
> - A API interface to open a "connection" to a background worker, run
> queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(),
> AutonomousSessionExecute(), etc. The communication happens using the
> client/server protocol
On Wed, Aug 31, 2016 at 3:11 PM, Craig Ringer wrote:
>
> I suspect that there'll be way too much code that relies on stashing
> xact-scoped stuff in globals for that to be viable. Caches alone.
> Peter will be able to explain more, I'm sure.
>
> We'd probably need a new transaction data object tha
On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote:
> So doing autonomous transactions inside a single backend doesn't gain
> you very much, yet it is an enormously invasive patch to do it that
> way, not least because it requires you to rewrite locking and
> deadlocks to make them work correctly
On Wed, Aug 31, 2016 at 3:01 PM, Tom Lane wrote:
>
> Uh, not as subtly as all that, because "select * from sequence" will
> now return a different set of columns, which will flat out break a
> lot of clients that use that method to get sequence properties.
So? Clients expect changes like this bet
On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs wrote:
> On 6 September 2016 at 19:59, Tom Lane wrote:
>
>> The idea of looking to the stats to *guess* about how many tuples are
>> removable doesn't seem bad at all. But imagining that that's going to be
>> exact is folly of the first magnitude.
>
>
On Fri, Sep 9, 2016 at 1:01 PM, Heikki Linnakangas wrote:
> I'm happy with what it looks like. We are in fact getting a more sequential
> access pattern with these patches, because we're not expanding the pre-read
> tuples into SortTuples. Keeping densely-packed blocks in memory, instead of
> Sort
On Thu, Sep 8, 2016 at 9:29 AM, Andrew Borodin wrote:
>>autoconf check for IEEE 754 floats
> Autoconf man says folowing:
>>it is safe to assume IEEE-754 in most portable code these days
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Floating-Point-Portability
Personally I wouldn't
On Thu, Sep 22, 2016 at 3:23 AM, Tom Lane wrote:
> But to kick the hash AM as such to the curb is to say
> "sorry, there will never be O(1) index lookups in Postgres".
Well there's plenty of halfway solutions for that. We could move hash
indexes to contrib or even have them in core as experimenta
On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund wrote:
> Any plans to pick this up again?
Yeah, I was just thinking I should pick this up again.
> I vote for renaming the VALGRIND names etc. to something more tool-neutral. I
> think it's going to be too confusing otherwise.
Hm, the danger ther
On Wed, Sep 28, 2016 at 7:40 AM, Piotr Stefaniak
wrote:
> Not remembering the context, I was initially confused about what exactly
> supposedly needs to be done in order to have ASan support, especially
> since I've been using it for a couple of years without any kind of
> modifications. Having re
There are some unanswered questions with column grants too. Do we
allow granting access to a calculated column which accesses columns
the user doesn't have access to?
If so then this is a suitable substitute for using updateable views to
handle things like granting users access to things like pass
On 8 October 2017 at 08:52, Andrey Borodin wrote:
>
> 1. Any other marker would be better (It can be WAL scan during archiving,
> some new LSN-based mechanics* et c.)
The general shape of what I would like to see is some log which lists
where each checkpoint starts and ends and what blocks are m
On 10 October 2017 at 23:50, Stephen Frost wrote:
> Yeah, it sounds interesting, but I was just chatting w/ David about it
> and we were thinking about how checkpoints are really rather often done,
> so you end up with quite a few of these lists being out there.
>
> Now, if the lists were always k
We already know this integer overflow checking is non-standard and
compilers keep trying to optimize them out. Our only strategy to
defeat that depends on compiler flags like -fwrapv that vary by
compiler and may or may not be working on less well tested compiler.
So if there's a nice readable an
On 31 October 2017 at 07:05, Chris Travers wrote:
> Hi;
>
> After Andres's excellent talk at PGConf we tried benchmarking
> effective_io_concurrency on some of our servers and found that those which
> have a number of NVME storage volumes could not fill the I/O queue even at
> the maximum setting
On Thu, Sep 29, 2016 at 8:46 PM, Tom Lane wrote:
> We could probably refactor things enough so that we do pq_init()
> before PGSharedMemoryReAttach(). It would be a little bit ugly,
> and it would fractionally increase the chance of a reattach failure
> because pq_init() palloc's a few KB worth o
On Fri, Sep 30, 2016 at 2:11 AM, Robert Haas wrote:
> For one thing, we can stop shipping a totally broken feature in release after
> release
For what it's worth I'm for any patch that can accomplish that.
In retrospect I think we should have done the hash-over-btree thing
ten years ago but we
On Sat, Oct 1, 2016 at 1:44 AM, Andres Freund wrote:
>
> Unfortunately I'm running out battery right now, so I don't want to
> re-run the benchmarks posted upthread (loading takes a while). But the
> last time I ran them all the results after the patches were better than
> before.
I have a machi
On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane wrote:
> pg_dump alleges support for dumping from servers back to 7.0. Would v10
> be a good time to remove some of that code? It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f2
On Mon, Oct 10, 2016 at 3:36 AM, Jim Nasby wrote:
> FWIW, Greg Stark did a talk at PG Open about PG performance going back to at
> least 7.4. He did discuss what he had to do to get those versions to compile
> on modern tools, and has a set of patches that enable it. Unfortunately his
On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark wrote:
>
> The code is here:
>
> https://github.com/gsstark/retropg
>
> The build script is called "makeall" and it applies patches from the
> "old-postgres-fixes" directory though some of the smarts are in the
&
On Sat, Feb 6, 2016 at 4:52 AM, Noah Misch wrote:
> aset.c relies on the fact that VALGRIND_MEMPOOL_ALLOC() has an implicit
> VALGRIND_MAKE_MEM_UNDEFINED() and VALGRIND_MEMPOOL_FREE() has an implicit
> VALGRIND_MAKE_MEM_NOACCESS(). #define those two accordingly. If ASAN has no
Actually this is
[resending to -hackers sorry]
Back in 2001 a hack to add __attribute__((packed)) to ItemPtr was
added with a comment "Appropriate whack upside the head for ARM"
(dcbbdb1b3ee). I don't know if this is still a factor in 2016 or not
but it has already resulted in some collateral damage in 2015 when
s
On Wed, Oct 19, 2016 at 5:20 PM, Tom Lane wrote:
> Don't know how that version number compares to "3.8.0".
Argh. Just to further confuse matters apparently the warnings are from
clang 4.0. I had been testing with 3.8.0 earlier but updated at some
point.
And I'm not being able to reproduce them w
Ah. Here we go:
$ /usr/bin/clang-4.0 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -Wno-unused-command-line-argument -Wall -c clang-bug.c
clang-bug.c:54:9: error: use of undeclared
Sorry -- with the obvious error fixed:
$ /usr/bin/clang-4.0 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -Wno-unused-command-line-argument -Wall -c clang-bug.c
clang-bug.c:55:9: w
On Oct 20, 2016 5:27 PM, "Noah Misch" wrote:
>
> On Wed, Oct 19, 2016 at 11:08:39AM +0100, Greg Stark wrote:
>
> > The MEMPOOL_FREE doesn't take any size argument and mcxt.c doesn't
> > have convenient access to a size argument. It could call the
> >
On Fri, Oct 21, 2016 at 9:03 PM, Stephen Frost wrote:
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
> login
> 0 upgraded, 0 newly installed, 1 to remove and 71 not upgraded.
> After this operation, 1,212 kB disk
On Wed, Oct 26, 2016 at 11:04 PM, Joshua D. Drake
wrote:
> On 10/26/2016 12:54 PM, Josh Berkus wrote:
>> I mean, I'm not particularly in favor of using JSON for this (arrays
>> seem OK), but that seems like an invalid reason not to.
>
> -1 to JSON for this.
Sigh. Well I tried to review this patc
On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure wrote:
> I think we can rule out faulty storage
Nobody ever expects the faulty storage
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
This sounds amazing.
My only comment is that LLVM 3.7 is kind of old in the accelerated world of
LLVM. If you have patches to LLVM you need you won't have much success
submitting them as patches on 3.7.
The current stable release is 3.9 and the development snapshots are 4.0. I
know LLVM moves qui
On Sun, Nov 13, 2016 at 3:45 PM, Magnus Hagander wrote:
> For a scenario like this, would it make sense to have an option that could
> be set on an individual table making it physical append only? Basically
> VACUUM would run as normal and clean up the old space when rows are deleted
> back in his
On Tue, Nov 15, 2016 at 4:50 PM, Robert Haas wrote:
> On Sun, Nov 13, 2016 at 9:48 AM, Andrew Dunstan wrote:
>> I'm not convinced the line prefix part is necessary, though. What I'm
>> thinking of is something like this:
>>
>> PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=
On 15 February 2017 at 12:52, Robert Haas wrote:
> Personally, I find it somewhere in the middle: I think the way it
> works now is reasonable, and I think what he wants would have been
> reasonable as well. However, I find it hard to believe it would be
> worth changing now on backward compatibi
On 22 February 2017 at 15:08, Tom Lane wrote:
> Indeed. When I wrote the comment you're referring to, quite a few years
> ago now, I thought that popular demand might force us to allow omitted
> aliases. But the demand never materialized. At this point it seems
> clear to me that there isn't re
On 23 February 2017 at 13:27, Greg Stark wrote:
> => SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x;
Oops, I missed the typo there:
=> SELECT "?column?" FROM (select 1+1 AS "?column?", 1+1) AS x;
ERROR: 42702: column reference "
On 24 February 2017 at 14:57, David G. Johnston
wrote:
> I dislike an error. I'd say that making partition "just work" here is
> material for another patch. In this one an update of the partition key can
> be documented as shorthand for delete-returning-insert with all the
> limitations that go
On 2 March 2017 at 13:03, amul sul wrote:
> create table foo (a integer, b text) partition by hash (a);
> create table foo1 partition of foo with (modulus 4, remainder 0);
> create table foo2 partition of foo with (modulus 8, remainder 1); -- legal,
> modulus doesn't need to match
> create table
On 18 March 2017 at 22:22, Peter Geoghegan wrote:
>
> Out of idle curiosity, I decided to generate disassembly of both
> macaddr_cmp_internal(), and the patch's abbreviated comparator. The
> former consists of 49 x86-64 instructions at -02 on my machine,
> totaling 135 bytes of object code. The la
On Wed, Jun 11, 2014 at 3:26 PM, Tom Lane wrote:
> If we didn't have mechanisms like this, we'd have far worse hazards from
> ALTER TABLE than whether the planner made an incorrect join optimization.
> Consider ALTER COLUMN TYPE for instance.
Obviously not general cases of ALTER COLUMN TYPE but d
On Wed, Jun 11, 2014 at 7:52 PM, Peter Eisentraut wrote:
> On 6/8/14, 11:29 PM, Noah Misch wrote:
>> The patch did not restore 9.3 behavior for that one. Starting with commit
>> 6513633, the first line of letters is space-padded on the right to the width
>> of the second line of letters. To illu
And Gmail has thoroughly mangled that email. Let me see if I can
resend it from Emacs more clearly.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jun 16, 2014 at 9:05 PM, Robert Haas wrote:
> So, it seems like we need to do something about this one way or
> another. Who's working on that?
So I'm fine finishing what I started. I've just been a bit busy this past week.
My inclination is to try to push forward and commit this patch,
On Mon, Jun 16, 2014 at 9:08 PM, Robert Haas wrote:
> What happens if the limit is exceeded? ERROR? FATAL? PANIC?
Well presumably it just makes malloc return NULL which causes an
ERROR. One advantage to setting it via a GUC is that it might be
possible to, for example, raise it automatically i
On Tue, Jun 17, 2014 at 3:31 PM, Andres Freund wrote:
> Is there actually a significant usecase behind that wish or just a
> general demand for being generic? To me it seems fairly unlikely you'd
> end up with something useful by doing a minmax index over bounding
> boxes.
Isn't min/max just a 2d
On Tue, Jun 17, 2014 at 11:16 AM, Andres Freund wrote:
> Well, it might be doable to correlate them along one axis, but along
> both? That's more complicated... And even alongside one axis you
> already get into problems if your geometries are irregularly sized.
> Asingle large polygon will compl
On Wed, Jun 18, 2014 at 4:51 AM, Heikki Linnakangas
wrote:
> Implementing something is a good way to demonstrate how it would look like.
> But no, I don't insist on implementing every possible design whenever a new
> feature is proposed.
>
> I liked Greg's sketch of what the opclass support functi
On Wed, May 28, 2014 at 2:19 PM, Heikki Linnakangas
wrote:
> How portable is POSIX aio nowadays? Googling around, it still seems that on
> Linux, it's implemented using threads. Does the thread-emulation
> implementation cause problems with the rest of the backend, which assumes
> that there is on
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas wrote:
> However, we don't know of anyone who has tried to do this in a very
> long time, and are therefore considering removing the remaining
> support for the VAX platform. Has anyone tried to build PostgreSQL
> for VAX lately?
Actually I tried a wh
On Mon, Jun 23, 2014 at 2:43 PM, John Lumby wrote:
> It is when some *other* backend gets there first with the ReadBuffer that
> things are a bit trickier.The current version of the patch did polling
> for that case
> but that drew criticism,and so an imminent new version of the patch
> u
On Tue, Jun 24, 2014 at 12:02 AM, Soroosh Sardari
wrote:
> Is there any rule for adding a field to PageHeaderData?
Not really. It's a pretty internal thing, not something we expect
people to be doing all the time.
The only rule I can think of is that you should bump some version
numbers such as
On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas wrote:
> Well, the fact that initdb didn't produce a working configuration and
> that make installcheck failed to work properly are bad. But, yeah,
> it's not totally broken.
Yeah it seems to me that these kinds of autoconf and initdb tests
failing a
Zombie thread arise!
I was searching for old threads on a specific problem and came across
this patch that was dropped due to concerns about SnapshotNow:
On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas wrote:
> On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark wrote:
>> Well it's super-ex
Why is this even a small concern? Initdb runs the bootstrap SQL which does
various SQL operations so it's not surprising there are some updates
creating garbage. Iirc we don't even rely on template0 being frozen any
more.
--
greg
I think log_error_verbosity is a strange variable. It's useless for
expected user-facing errors but essential for unexpected errors that
indicate bugs in the code -- and you can only have it on for
everything or off for everything.
I'm finding I usually want it set to 'verbose' for anything that
P
On Thu, Jul 3, 2014 at 11:40 AM, Atri Sharma wrote:
> IIRC, last time when we tried doing bloom filters, I was short of some real
> world useful hash functions that we could use for building the bloom filter.
Last time was we wanted to use bloom filters in hash joins to filter
out tuples that won
On Thu, Jul 3, 2014 at 7:37 AM, Tom Lane wrote:
> TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy
> in that the application would have little idea what it was getting back.
> IF EXISTS would make it so spongy as to be useless, IMO.
Seems easy enough to look at the count of colum
On Sun, Jul 6, 2014 at 8:40 AM, Sergey Muraviov
wrote:
> Is there anyone who can commit the patch?
So what I'm inclined to do here (sigh) is commit it into 9.5 and
revert it in 9.4. I think it's an improvement but I there's enough
confusion and surprise about the changes from people who weren't
e
On Mon, Jul 7, 2014 at 3:07 PM, Tom Lane wrote:
> I doubt it. The extra code isn't the problem so much, it's the extra
> planning cycles spent trying to make proofs that will usually fail.
> What you propose will create a combinatorial explosion in the number
> of proof paths to be considered.
W
On Wed, Jul 9, 2014 at 7:29 AM, Peter Geoghegan wrote:
> Everyone is going to have an opinion on something like that. I was
> showing deference to the general concern about the absolute (as
> opposed to relative) quality of the HINTs in the event of equidistant
> matches by having no two suggestio
On Wed, Jul 9, 2014 at 10:16 PM, Alvaro Herrera
wrote:
> there is no hardcoded assumption on the number of index
> values stored per heap column, so it is possible to build an opclass
> that stores a bounding box column for a geometry heap column, for
> instance.
I think the more Postgresy thing
On Mon, Jul 7, 2014 at 8:35 AM, Sergey Muraviov
wrote:
> So what's wrong with the patch?
> And what should I change in it for 9.5?
Possibly nothing. The concern was tha it's modifying the output in
cases where the output is not \expanded and/or not wrapped. Now I've
mostly convinced myself that t
On Thu, Jul 10, 2014 at 10:29 PM, Alvaro Herrera
wrote:
>
> What I think should happen is that if the value is changed, the index
> sholud be rebuilt right there.
I disagree. It would be a non-orthogonal interface if ALTER TABLE
sometimes causes the index to be rebuilt and sometimes just makes a
On Fri, Jul 11, 2014 at 6:00 PM, Claudio Freire wrote:
> Marking as read-only is ok, or emitting a NOTICE so that if anyone
> changes those parameters that change the shape of the index, they know
> it needs a rebuild would be OK too. Both mechanisms work for me.
We don't actually have any of the
We've observed a 9.0 database have undetected deadlocks repeatedly in
hot standby mode.
I think what's happening is that autovacuum is kicking off a VACUUM of
some system catalogs -- it seems to usually be pg_statistics' toast
table actually. At the end of the vacuum it briefly gets the exclusive
On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon wrote:
> Except, of course, for IEEE floating point, because the VAX's floating point
> unit simply does not provide that
Actually I think that's relevant. We usually get focused on the
concurrency because that's an area where architectures var
On Thu, Jul 17, 2014 at 4:04 PM, Johnny Billquist wrote:
> Also, VAX did not use CAS as the general paradigm for atomic writes and so
> on, but have other explicit instructions that are guaranteed to be atomic.
> NetBSD/vax don't use the VAX specific instructions, but emulates CAS in the
> kernel
If you're always going FPW then there's no point in the rest of the record.
The point here was to find problems so that users could run normally with
confidence.
The cases you might want to run in the mode you describe are the build farm
or integration testing. When treating your application on th
On Wed, Jul 23, 2014 at 5:58 PM, Robert Haas wrote:
> I'd suggest something like:
>
> UPSERT table SET col = value [, ...] WHERE predicate;
I don't think this is actually good enough. Typical use cases are
things like "increment this counter or insert a new one starting at
0".
--
greg
--
Sen
On Sun, Jul 27, 2014 at 8:00 AM, Peter Geoghegan wrote:
> What may be of more interest to reviewers is the revised AC_TRY_RUN
> test program that "configure" consults.
I haven't looked yet. Can you describe what exactly the AC_TRY_RUN is
testing for?
If it's just whether the system supports strx
On Thu, Jul 31, 2014 at 8:14 PM, Marti Raudsepp wrote:
> On Thu, Jul 31, 2014 at 9:41 PM, Robert Haas wrote:
>> I certainly like that better than poor-man; but proxy, to me, fails to
>> convey inexactness.
>
> Maybe "abbreviated", "abridged", "minified"?
Surrogate?
Let the bike shedding begin!
On 15 Aug 2014 19:06, "Robert Haas" wrote:
>
> > As for the expanded-mode changes, I thought there was consensus to
> > revert that from 9.4.
>
> Me too. In fact, I think that's been the consensus for many months,
> but unless I'm mistaken it ain't done.
Yeah, this is entirely my fault. I was tr
On Tue, Aug 5, 2014 at 3:41 AM, Noah Misch wrote:
> This remains open for 9.4. Your proposal to revert the feature in 9.4 and fix
> it in 9.5 sounds reasonable.
Ok, I've gone ahead and done this. I'm sorry for the delays and confusion.
> On Thu, Jul 10, 2014 at 04:15:35P
On Mon, Aug 18, 2014 at 12:55 PM, Michael Paquier
wrote:
> I imagine that you also need to fix the release notes accordingly.
> Patch attached for master and REL9_4_STABLE.
Thanks.
Done for 9.4 but the patch is still in master. In fact it's the most
recent version and I'm still pretty convinced
On 15 Aug 2014 14:54, "Tom Lane" wrote:
>
> Andres Freund writes:
> > On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
> >> And what does that actually do? Send back a result-set, or a new
> >> protocol message?
>
> > What I was thinking of was to return "COMMIT X/X" instead of
> > "COMMIT". Sin
1 - 100 of 2942 matches
Mail list logo
