[HACKERS] Re: Anyone have experience benchmarking very high effective_io_concurrency on NVME's?

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

Re: [HACKERS] Current int & float overflow checking is slow.

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

Re: [HACKERS] On markers of changed data

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

Re: [HACKERS] On markers of changed data

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

Re: [HACKERS] generated columns

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

Re: [HACKERS] 64-bit queryId?

On 1 October 2017 at 16:40, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@mit.edu> writes: >> Indeed. It's simple enough to export stats to prometheus with queryid >> as the key. Then even if the query ages out of the database stats you >> have gr

Re: [HACKERS] 64-bit queryId?

On 30 September 2017 at 21:03, Alexander Korotkov wrote: > I heard from customers that they periodically dump contents of > pg_stat_statements and then build statistics over long period of time. If > even they leave default pg_stat_statements.max unchanged,

Re: [HACKERS] The case for removing replacement selection sort

On 8 September 2017 at 18:06, Peter Geoghegan wrote: > * It's still faster with int4/int8 comparisons on modern hardware, and > I think that most ordered inputs will be of those types in practice. This may be a bit "how long is a piece of string" but how do those two compare with

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

On 5 September 2017 at 11:58, Konstantin Knizhnik wrote: > > I wonder if we can perform some optimization in this case (assuming that in > typical cases column either contains mostly non-null values, either mostly > null values). If you really wanted to go crazy here

[HACKERS] CSV Logging questions

I was just looking over the CSV logging code and have a few questions about why things were done the way they were done. 1) Why do we gather a per-session log line number? Is it just to aid people importing to avoid duplicate entries from partial files? Is there some other purpose given that

Re: [HACKERS] log_destination=file

On 31 August 2017 at 13:49, Tom Lane wrote: > Magnus Hagander writes: >> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: > Yes, it's pretty important, because of assorted stuff not-under-our- > control that doesn't know about ereport

[HACKERS] signed logging format for pid in log_line_prefix?

Both the text and csv logging seem to use %d on for logging the server pid: appendStringInfo(buf, "%d", MyProcPid); Am I missing something or wouldn't this mean we print pids with large values as negative numbers? Isn't that strange? Wouldn't we rather use %u here? -- greg -- Sent via

Re: [HACKERS] generated columns

On 31 August 2017 at 05:16, Peter Eisentraut wrote: > Here is another attempt to implement generated columns. This is a > well-known SQL-standard feature, also available for instance in DB2, > MySQL, Oracle. A quick example: > > CREATE TABLE t1 ( > ..., >

Re: [HACKERS] MAIN, Uncompressed?

On 25 August 2017 at 19:59, Simon Riggs wrote: > > On 25 August 2017 at 14:08, Tom Lane wrote: > > > Maybe, but the use case seems mighty narrow. > > JSON blobs between 2kB and 8160 bytes are very common. > > String length is maybe a poisson

Re: [HACKERS] Funny WAL corruption issue

On 10 August 2017 at 15:26, Chris Travers wrote: > > > The bitwise comparison is interesting. Remember the error was: > > pg_xlogdump: FATAL: error in WAL record at 1E39C/E1117FB8: unexpected > pageaddr 1E375/61118000 in log segment 0001E39C00E1, offset >

Re: [HACKERS] More optimization effort?

On 21 July 2017 at 20:00, Tom Lane wrote: >> I have, however, decided not to volunteer to be the one who works on >> that project. > > Me either. Any one of these things would require a *lot* of work in > order to have a coherent feature that provided useful behavior across

Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

On 20 July 2017 at 14:19, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@mit.edu> writes: > >> Would it be useful to keep in one of the memory checking assertion builds? > > Why? Code that expects to continue accessing a relcache entry's tupdesc >

Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

On 19 July 2017 at 00:26, Tom Lane wrote: > It's probably a bit late in the v10 cycle to be taking any risks in > this area, but I'd vote for ripping out RememberToFreeTupleDescAtEOX > as soon as the v11 cycle opens, unless someone can show an example > of non-broken coding

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

On 15 July 2017 at 23:00, Tom Lane wrote: > While it's too late in the v10 cycle to do anything very meaningful > about this now, I am tempted to strengthen the deprecation notice's > wording from "might disappear" to "will disappear". "Will certainly disappear at some

Re: [HACKERS] building libpq.a static library

On 12 July 2017 at 16:11, Tom Lane wrote: > Jeroen Ooms writes: > >> This works but it's a bit of a pain to maintain. I was wondering if >> this hack could be merged so that the standard 'configure >> --enable-static' script would install a static library

Re: [HACKERS] New partitioning - some feedback

On 10 July 2017 at 23:46, David Fetter wrote: > On Mon, Jul 10, 2017 at 05:33:34PM -0500, Robert Haas wrote: >> On Mon, Jul 10, 2017 at 2:15 AM, Amit Langote >> wrote: >> > I posted a patch upthread which makes \d hide partitions >> >

Re: [HACKERS] RFC: Key normalization for nbtree

On 10 July 2017 at 19:40, Peter Geoghegan wrote: > Key normalization means creating a representation for internal page > items that we always just memcmp(), regardless of the details of the > underlying datatypes. One thing I would like to see is features like this added to the

Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

On 6 July 2017 at 15:29, Jim Finnerty wrote: > > Feel free to knock down this 'straw man' and propose something better! I think the pattern in this design that we don't want is that it imposes extra complexity on every user of every page even when the page doesn't have the

Re: [HACKERS] WIP patch for avoiding duplicate initdb runs during "make check"

On 2 July 2017 at 18:33, Tom Lane wrote: > system("cp -a ...") call in favor of something more portable. If we're ok with using Perl there's File::Copy::Recursive::dircopy() which does exactly that. -- greg -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Notes on testing Postgres 10b1

On 7 June 2017 at 01:01, Josh Berkus wrote: > P3: apparently jsonb_to_tsvector with lang parameter isn't immutable? > This means that it can't be used for indexing: > > libdata=# create index bookdata_fts on bookdata using gin (( > to_tsvector('english',bookdata))); > ERROR:

Re: [HACKERS] Hash Functions

On 13 May 2017 at 10:29, Robert Haas wrote: > - Floats. There may be different representations in use on different > hardware, which could be a problem. Tom didn't answer my question > about whether any even-vaguely-modern hardware is still using non-IEEE > floats, which

Re: [HACKERS] A design for amcheck heapam verification

On 1 May 2017 at 20:46, Robert Haas wrote: > One problem is that Bloom filters assume you can get > n independent hash functions for a given value, which we have not got. > That problem would need to be solved somehow. If you only have one > hash function, the size of the

Re: [HACKERS] Logical replication in the same cluster

On 1 May 2017 at 19:24, Andres Freund wrote: >> There is no inherent reason why the CREATE INDEX CONCURRENTLY style of >> using multiple transactions makes it necessary to leave a mess behind >> in the event of an error or hard crash. Is someone going to get around >> to

Re: [HACKERS] multithreading in Batch/pipelining mode for libpq

On 21 April 2017 at 21:31, Ilya Roublev wrote: > What I need is to make a huge amount of inserts This may be a silly question but I assume you've already considered using server-side COPY? That's the most efficient way to load a lot of data currently. -- greg -- Sent

Re: [HACKERS] Highly Variable Planning Times

On 19 April 2017 at 22:39, Michael Malis wrote: >> *At best*, you're doing substantial work in the >> planner to avoid the first tree descent step or two in a single >> non-partial index. Fwiw, in addition to replacing the first few levels of the descent with

Re: [HACKERS] Some thoughts about SCRAM implementation

On 14 April 2017 at 20:20, Peter Eisentraut wrote: > > Yeah, I think if you're concerned about MITM then you would also be > concerned about MITM siphoning off your data. So you should be using > TLS and then you don't need channel binding. No. You can use TLS

Re: [HACKERS] Variable substitution in psql backtick expansion

On 2 April 2017 at 07:53, Fabien COELHO wrote: > Note that this is already available indirectly, as show in the > documentation. > > SELECT some-boolean-expression AS okay \gset > \if :okay > \echo boolean expression was true > \else > \echo boolean expression

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 4 April 2017 at 17:10, Maksim Milyutin wrote: > > 3. As I noticed early pg_depend table is used for cascade deleting indexes > on partitioned table and its children. I also use pg_depend to determine > relationship between parent and child indexes when reindex

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On 21 March 2017 at 20:04, Bruce Momjian wrote: > Yes, but once it is written it will take years before those bits can be > used on most installations. Well the problem isn't most installations. On most installations it should be pretty straightforward to check the oldest

Re: [HACKERS] [PATCH] SortSupport for macaddr type

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

Re: [HACKERS] [POC] hash partitioning

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

Re: [HACKERS] UPDATE of partition key

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

Re: [HACKERS] Make subquery alias optional in FROM clause

On 23 February 2017 at 13:27, Greg Stark <st...@mit.edu> 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:

Re: [HACKERS] Make subquery alias optional in FROM clause

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

Re: [HACKERS] Sum aggregate calculation for single precsion real

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

Re: [HACKERS] UPDATE of partition key

On 13 February 2017 at 12:01, Amit Khandekar wrote: > There are a few things that can be discussed about : If you do a normal update the new tuple is linked to the old one using the ctid forming a chain of tuple versions. This tuple movement breaks that chain. So the

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On 11 February 2017 at 23:45, Corey Huinker wrote: > So you'd just want to know nesting depth, with no indicator of true/false? Even that's more than bash does, for example: $ if true ; then > if false ; then > : > fi > fi I'm a bit confused how the true/false is

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On 10 February 2017 at 21:36, Fabien COELHO wrote: >> command prompt is now >> --- --- >> \echo bob '' = initial state, no branch going on at all >> \if yes 't' = inside a true branch >> \if no'tf' =

Re: [HACKERS] GSoC 2017

On 27 January 2017 at 14:52, Thomas Kellerer wrote: > > I don't have the exact syntax at hand, but it's something like this: > > create distinct type customer_id_type as integer; > create distinct type order_id_type as integer; > > create table customers (id customer_id_type

Re: [HACKERS] GSoC 2017

On 24 January 2017 at 03:42, Peter van Hardenberg wrote: > The basic concept is that the value of a currency type is that it would > allow you to operate in multiple currencies without accidentally adding > them. You'd flatten them to a single type if when and how you wanted for any

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 25 January 2017 at 20:06, Jim Nasby wrote: > GUCs support SET LOCAL, but that's not the same as local scoping because the > setting stays in effect unless the substrans aborts. What I'd like is the > ability to set a GUC in a plpgsql block *and have the setting revert

Re: [HACKERS] Checksums by default?

On 26 January 2017 at 01:58, Thomas Munro wrote: > > I don't know how comparable it is to our checksum technology, but > MySQL seems to have some kind of checksums on table data, and you can > find public emails, blogs etc lamenting corrupted databases by >

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

I tend to agree. But in the past when this came up people pointed out you could equally do things this way and still grant all the access you wanted using SECURITY DEFINER. Arguably that's a better approach because then instead of auditing the entire monitor script you only need to audit this one

Re: [HACKERS] Online enabling of page level checksums

On Jan 22, 2017 11:13 AM, "Magnus Hagander" wrote: Yes, this means the entire db will end up in the transaction log since everything is rewritten. That's not great, but for a lot of people that will be a trade they're willing to make since it's a one-time thing. Yes, this

Re: [HACKERS] RustgreSQL

On 8 January 2017 at 21:50, Jim Nasby wrote: > Somewhat related to that... it would be useful if Postgres had "fenced" > functions; functions that ran in a separate process and only talked to a > backend via a well defined API (such as libpq). There's two major

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 8 January 2017 at 17:26, Greg Stark <st...@mit.edu> wrote: > On 5 January 2017 at 19:01, Andres Freund <and...@anarazel.de> wrote: >> That's a bit odd - shouldn't the OS network stack take care of this in >> both cases? I mean either is too big for TCP packets

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 5 January 2017 at 19:01, Andres Freund wrote: > That's a bit odd - shouldn't the OS network stack take care of this in > both cases? I mean either is too big for TCP packets (including jumbo > frames). What type of OS and network is involved here? 2x may be plausible.

Re: [HACKERS] pg_stat_activity.waiting_start

On 6 January 2017 at 02:59, Bruce Momjian wrote: > > Agreed. No need in adding overhead for short-lived locks because the > milli-second values are going to be meaningless to users. I would be > happy if we could find some weasel value for non-heavyweight locks. For what it's

Re: [HACKERS] Cluster wide option to control symbol case folding

On 25 December 2016 at 09:40, Lewis, Ian (Microstar Laboratories) wrote: > So, the current behavior already breaks many tools unless one accepts > that all symbols on the server are lower case. At root, based on reading > the threads you provided, this probably indicates

Re: [HACKERS] pg_stat_activity.waiting_start

On Dec 24, 2016 5:44 PM, "Tom Lane" wrote: I think we'd need at least an order of magnitude cheaper to consider putting timing calls into spinlock or lwlock paths, and that's just not available at all, let alone portably. For spinlocks we could conceivably just bite the

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Dec 26, 2016 10:35 PM, "Tom Lane" wrote: So it seems like the configure support we'd need is to detect whether clock_gettime is available (note on Linux there's also a library requirement, -lrt), and we would also need a way to provide a platform-specific choice of

Re: [HACKERS] Declarative partitioning - another take

Just poking around with partitioning. I notice that "\d parent" doesn't list all the partitions, suggesting to use \d+ but a plain "\d" does indeed list the partitions. That seems a bit strange and also probably impractical if you have hundreds or thousands of partitions. Has this come up in

Re: [HACKERS] jsonb problematic operators

On 12 December 2016 at 04:59, Craig Ringer wrote: > I didn't realise Pg's use of ? was that old, so thanks. That makes > offering alternatives much less appealing. One option might be for Postgres to define duplicate operator names using ¿ or something else. I think ¿ is a

Re: [HACKERS] Separate connection handling from backends

On 5 December 2016 at 19:48, Jim Nasby wrote: > One solution to this would be to segregate connection handling from actual > backends, somewhere along the lines of separating the main loop from the > switch() that handles libpq commands. Benefits: I'm kind of mystified

Re: [HACKERS] Mail thread references in commits

On 30 November 2016 at 16:19, Andrew Dunstan wrote: > > https://www.postgresql.org/message-id/cab7npqthydyf-fo+fzvxrhz-7_hptm4rodbcsy9-noqhvet...@mail.gmail.com > > I'll be interested to know if it breaks anyone's MUA. If it doesn't all we > will be arguing about are

Re: [HACKERS] UNDO and in-place update

On 24 November 2016 at 23:03, Robert Haas wrote: >> For snapshot isolation Oracle has yet a *third* copy of the data in a >> space called the "rollback segment(s)". > > My understanding is that this isn't correct. I think the rollback > segments are what they call the

Re: [HACKERS] UNDO and in-place update

On 23 November 2016 at 04:28, Peter Geoghegan wrote: > On Tue, Nov 22, 2016 at 7:01 PM, Robert Haas wrote: >> This basic DO-UNDO-REDO protocol has been well-understood for >> decades. > > FWIW, while this is basically true, the idea of repurposing UNDO to

[HACKERS] Re: Do we need use more meaningful variables to replace 0 in catalog head files?

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

Re: [HACKERS] Physical append-only tables

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

Re: [HACKERS] JIT compiler for expressions

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

Re: [HACKERS] emergency outage requiring database restart

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:

Re: [HACKERS] pg_hba_file_settings view patch

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

Re: [HACKERS] Renaming of pg_xlog and pg_clog

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

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

On Oct 20, 2016 5:27 PM, "Noah Misch" <n...@leadboat.com> 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 co

Re: [HACKERS] [COMMITTERS] packing/alignment annotation for ItemPointerData redux

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:

Re: [HACKERS] [COMMITTERS] packing/alignment annotation for ItemPointerData redux

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

Re: [HACKERS] [COMMITTERS] packing/alignment annotation for ItemPointerData redux

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

[HACKERS] packing/alignment annotation for ItemPointerData redux

[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

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

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

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark <st...@mit.edu> 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

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

On Mon, Oct 10, 2016 at 3:36 AM, Jim Nasby <jim.na...@bluetreble.com> 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 patc

Re: [HACKERS] Is it time to kill support for very old servers?

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

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

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 >

Re: [HACKERS] Hash Indexes

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

Re: [HACKERS] Order of operations in SubPostmasterMain()

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()

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

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

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

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.

Re: [HACKERS] Hash Indexes

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

Re: [HACKERS] GiST penalty functions [PoC]

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

Re: [HACKERS] Tuplesort merge pre-reading

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,

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

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 >>

Re: [HACKERS] pg_sequence catalog

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

Re: [HACKERS] autonomous transactions

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

Re: [HACKERS] autonomous transactions

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

Re: [HACKERS] autonomous transactions

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

Re: [HACKERS] Pinning a buffer in TupleTableSlot is unnecessary

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

Re: [HACKERS] Fix some corner cases that cube_in rejects

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 >

[HACKERS] Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

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

Re: [HACKERS] Are these supported??

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

Re: [HACKERS] Are these supported??

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

Re: [HACKERS] Why we lost Uber as a user

On Wed, Aug 17, 2016 at 1:36 AM, Jim Nasby wrote: > Something I didn't see mentioned that I think is a critical point: last I > looked, HOT standby (and presumably SR) replays full page writes. That means > that *any* kind of corruption on the master is *guaranteed* to

Re: [HACKERS] [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer wrote: > I'm surprised the 32-bit xid was ever exposed to the user, rather than a > 64-bit epoch-extended xid. Once upon a time we didn't have epoch counting at all. I don't think it would be a bad idea to clean up everything

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On Tue, Aug 16, 2016 at 12:41 AM, Josh Berkus wrote: > Presumably people just need to add the system account tag to the unit > file, no? That's a system level change though. How would a normal user manage this? -- greg -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs

On Mon, Aug 15, 2016 at 11:45 PM, Peter Eisentraut wrote: > If we instead installed > > libpq.so.5 (actual file) > libpq.so -> libpq.so.5 > > nothing would effectively change. It would make it impossible to have multiple versions installed. One doesn't normally

Re: [HACKERS] Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)

On Sat, Aug 13, 2016 at 1:18 AM, Andrew Gierth wrote: > > Hmm? The code in _bt_findsplitloc and _bt_checksplitloc doesn't seem to > agree with this. > > (Inserting on the high leaf page is a special case, which is where the > fillfactor logic kicks in; that's why

  1   2   3   4   5   6   7   8   9   10   >