Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-09 16:45:07 -0800, Peter Geoghegan wrote: > On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund <and...@anarazel.de> wrote: > >> Actually, on second thought, I take that back -- I don't think that > >> REINDEXing will even finish once a HOT chain is broken by the b

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

REINDEXing will even finish once a HOT chain is broken by the bug. > IndexBuildHeapScan() actually does quite a good job of making sure > that HOT chains are sane, which is how the enhanced amcheck notices > the bug here in practice. I think that's too optimistic. Greetings, Andres

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-04 06:15:00 -0700, Andres Freund wrote: > The reason for that is that I hadn't yet quite figured out how the bug I > described in the commit message (and the previously committed testcase) > would cause that. I was planning to diagnose / experiment more with this > and wr

Re: [HACKERS] pageinspect option to forgo buffer locking?

On 2017-11-09 17:14:11 -0500, Tom Lane wrote: > If we do this, I'd suggest exposing it as a separate SQL function > get_raw_page_unlocked() rather than as an option to get_raw_page(). > > The reasoning is that if we ever allow these functions to be controlled > via GRANT instead of hardwired

Re: [HACKERS] pageinspect option to forgo buffer locking?

On 2017-11-09 12:55:30 -0500, Robert Haas wrote: > On Thu, Nov 9, 2017 at 12:49 PM, Andres Freund <and...@anarazel.de> wrote: > > Occasionally, when debugging issues, I find it quite useful to be able > > to do a heap_page_items() on a page that's actually locked exclusively

[HACKERS] pageinspect option to forgo buffer locking?

to pass arbitrary stuff to heap_page_items(). Since pinning wouldn't be changed, there's no danger of the page being moved out from under us. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

indicated socket, clear internal network event records, and reset event objects (optional)." Note that it clears the state from the socket, *not* just the handle. That behaviour of WSAEnumNetworkEvents() also seems to explains why http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f7819b

Re: [HACKERS] Small improvement to compactify_tuples

items, which is cache inefficient. So instead we should sort items as [1/2, 1/4, 3/4, ...] elements, which will access items in a close-ish to linear manner. But that's fairly independent of pruning, so I'm not sure whether that's what you're referring to, either. Greetings, Andres Freund

Re: [HACKERS] Parallel Hash take II

Hi, @@ -747,7 +747,7 @@ try_hashjoin_path(PlannerInfo *root, * never have any output pathkeys, per comments in create_hashjoin_path. */ initial_cost_hashjoin(root, , jointype, hashclauses, - outer_path, inner_path, extra);

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

On November 8, 2017 7:31:17 AM PST, Peter Eisentraut wrote: >On 10/7/17 16:46, Tom Lane wrote: >> I wrote: >>> Current status is that I've filed a bug report with Apple and am >waiting >>> to see their response before deciding what to do next. If they fix

Re: [HACKERS] Parallel Hash take II

Hi, * avoids wasting memory on duplicated hash tables * avoids wasting disk space on duplicated batch files * avoids wasting CPU executing duplicate subplans What's the last one referring to? +static void +MultiExecParallelHash(HashState *node) +{ + switch

Re: [HACKERS] Parallel Hash take II

Hi, Here's a review of v24 +set min_parallel_table_scan_size = 0; +set parallel_setup_cost = 0; +-- Make a simple relation with well distributed keys and correctly +-- estimated size. +create table simple as + select generate_series(1, 2) AS id, 'aa'; +alter

Re: [HACKERS] [POC] Faster processing at Gather node

Hi, On 2017-11-06 10:56:43 +0530, Amit Kapila wrote: > On Sun, Nov 5, 2017 at 6:54 AM, Andres Freund <and...@anarazel.de> wrote > > On 2017-11-05 01:05:59 +0100, Robert Haas wrote: > >> skip-gather-project-v1.patch does what it says on the tin. I still > >> don't

Re: [HACKERS] Small improvement to compactify_tuples

mentation: #define qsort(a,b,c,d) pg_qsort(a,b,c,d) Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [POC] Faster processing at Gather node

pecific stuff. Whereas tpcc is oltp, right? > correct In that case, could you provide before/after profiles of the performance changing runs? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www

Re: [HACKERS] [POC] Faster processing at Gather node

On November 6, 2017 7:30:49 AM PST, Jim Van Fleet <vanfl...@us.ibm.com> wrote: >Andres Freund <and...@anarazel.de> wrote on 11/05/2017 03:40:15 PM: > >hammerdb, in this configuration, runs a variant of tpcc Hard to believe that any of the changes here are

Re: [HACKERS] Early locking option to parallel backup

st allow it as a general option to LOCK, there's plenty other operational cases where the current "fair" behaviour is really annoying, e.g. when executing operational DDL/DML and such. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To ma

Re: [HACKERS] Restricting maximum keep segments by repslots

Hi, On 2017-10-31 18:43:10 +0900, Kyotaro HORIGUCHI wrote: > - distance: > how many bytes LSN can advance before the margin defined by > max_slot_wal_keep_size (and wal_keep_segments) is exhasuted, > or how many bytes this slot have lost xlog from restart_lsn. I don't think

Re: [HACKERS] Restricting maximum keep segments by repslots

of this mainly for logical slots. That seems more like a page read callback's job than xlogreader's. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Early locking option to parallel backup

will prevent the on-demand lock by the dump worker from being granted. It seems to me the correct fix here would be to somehow avoid the fairness logic in the parallel dump case - although I don't quite know how to best do so. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [POC] Faster processing at Gather node

Hi, On November 5, 2017 1:33:24 PM PST, Jim Van Fleet wrote: >Ran this change with hammerdb on a power 8 firestone > >with 2 socket, 20 core >9.6 base-- 451991 NOPM >0926_master -- 464385 NOPM >11_04master -- 449177 NOPM >11_04_patch -- 431423 NOPM >-- two socket

Re: [HACKERS] [POC] Faster processing at Gather node

On 2017-11-05 01:05:59 +0100, Robert Haas wrote: > skip-gather-project-v1.patch does what it says on the tin. I still > don't have a test case for this, and I didn't find that it helped very > much, but it would probably help more in a test case with more > columns, and you said this looked like

[HACKERS] Display number of heap accesses for index scans

ome degree from explain analyze. The number of index lookups that failed to return anything can be a critical performance factor in OLTP workloads. Therefore it seems like it'd be a good idea to extend the explain analyze output to include that information. Greetings, Andres Freund -- Sent

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-04 06:15:00 -0700, Andres Freund wrote: > The current testcase, and I think the descriptions in the relevant > threads, all actually fail to point out the precise way the bug is > triggered. As e.g. evidenced that the freeze-the-dead case appears to > not cause

Re: [HACKERS] [POC] Faster processing at Gather node

pinLockAcquire(>mq_mutex); > - v = mq->mq_bytes_written; > - *detached = mq->mq_detached; > - SpinLockRelease(>mq_mutex); > - > - return v; > -} You reference this function in a comment elsewhere: > + /* > + * Separate prior reads of mq_ring

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-03 12:36:59 -0700, Peter Geoghegan wrote: > Andres Freund <and...@anarazel.de> wrote: > > Here's that patch. I've stared at this some, and Robert did too. Robert > > mentioned that the commit message might need some polish and I'm not > > 100% sure about

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On November 4, 2017 1:22:04 AM GMT+05:30, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: >Peter Geoghegan wrote: >> Andres Freund <and...@anarazel.de> wrote: > >> > Staring at the vacuumlazy hunk I think I might have found a related >bug: >> >

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-02 06:05:51 -0700, Andres Freund wrote: > Hi, > > On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote: > > Andres Freund wrote: > > > I think the problem is on the pruning, rather than the freezing side. We > > > can't freeze a tuple if it has a

Re: [HACKERS] ArrayLists instead of List (for some things)

re optimized implementation are better is the parser, where we really don't ahead of time know the size of the data we're dealing with. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi, On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote: > Andres Freund wrote: > > I think the problem is on the pruning, rather than the freezing side. We > > can't freeze a tuple if it has an alive predecessor - rather than > > weakining this, we should be fixing th

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi, On 2017-09-28 14:47:53 +, Alvaro Herrera wrote: > Fix freezing of a dead HOT-updated tuple > > Vacuum calls page-level HOT prune to remove dead HOT tuples before doing > liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But > concurrent transaction commit/abort may turn

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

e worthwhile to see whether doing the merging ourselves allows for deeper queues. I think we really should start incorporating explicit prefetching in more places. Ordered indexscans might actually be one case that's not too hard to do in a simple manner - whenever at an inner node, prefetch the lea

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

Hi, On 2017-10-30 22:29:42 +0530, Robert Haas wrote: > On Mon, Oct 30, 2017 at 4:57 PM, Andres Freund <and...@anarazel.de> wrote: > > 0001) Introduces pg_{add,sub,mul}{16,32,64}_overflow(a, b, *result) > > These use compiler intrinsics on gcc/clang. If that's no

Re: [HACKERS] Remove secondary checkpoint

es where there's actual data recovery needed that's a lot more useful than randomly using checkpoint - 1. And it's an explicit expert only thing, without costing everyone. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your sub

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

Hi, On 2017-10-24 03:39:54 -0700, Andres Freund wrote: > Largely that's due to the overflow checks. > > For integers we currently do: > > #define SAMESIGN(a,b) (((a) < 0) == ((b) < 0)) > > /* >* Overflow check. If the inputs are of different signs th

Re: [HACKERS] An unlikely() experiment

On 2017-10-30 22:39:01 +1300, David Rowley wrote: > On 30 October 2017 at 22:34, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > > > On 2015-12-20 02:49:13 +1300, David Rowley wrote: > >> Alternatively, if there was some way to mark the path as cold fr

Re: [HACKERS] An unlikely() experiment

re out a way to do this. I just was thinking about this, and it turns out that __attribute__((cold)) does what we need here. We could just mark elog_start() and errstart() as cold, and afaict that should do the trick. Thanks to Jakub from #gcc for pointing that out. Greetings, Andres Freund

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

ROR: 22003: value out of range: overflow The current code gets slightly better if I put an unlikely() around just the isinf(val) in CHECKFLOATVAL. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.p

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

ow the maximum we can reach with that. The problem with the C99 stuff seems to be the external function calls. With either, one problem would be that we'd have to reset the overflow register before doing math, which isn't free either - otherwise some external function could have left it set to on. Greetin

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

On 2017-10-24 10:09:09 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > There's no comparable overflow handling to the above integer > > intrinsics. But I think we can still do a lot better. Two very different > > ways: > > > 1)

Re: [HACKERS] Remove secondary checkpoint

; * reduces disk space requirements on master > > * removes a minor bug in fast failover > > * simplifies code > > Doesn't it also make crash recovery less robust? I think it does the contrary. The current mechanism is, in my opinion, downright dangerous: https://www.postgresql.org/message-

Re: [HACKERS] [POC] hash partitioning

ng is not good enough or if you want me to do > more testing, thanks. This looks very good! Both the tests you did, and the results for hash_combineXX. I therefore think we can go ahead with that formulation of hash_combine64? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list

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

ting inf in these cases actually seems entirely reasonable. We already don't detect them in a bunch of cases anyway. I can't quite parse the standard's language around this. 2) Use platform specific float exception handling where available. We could at backend start, and in FloatExceptionHandler(), us feenableexcept() (windows has similar) to trigger SIGFPE on float overflow. 3) Magic? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function

es transaction cleanup. But when you > hit a scenario where that's not true, or when a scenario that used to > not require cleanup now does, nobody is going to consider that a PG bug. It'd probably be a good idea to expand on this in the sgml docs. This has confused quite anumber of people

Re: [HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function

reventing you from handling errors in bgworkers without restarting today. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

in array indexed by > tranche. But I have no time to test this idea. And I doubt it will give > cardinally better results (ie > 5%), so I think it is better to accept > patch in this way, and then experiment with per-tranche delay. I don't think tranches have any decent predictive power here. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Make SpinDelayStatus a bit lighter. > > It saves couple of instruction of fast path of spin-loop, and so makes > fast path of LWLock a bit faster (and in other places where spinlock is > used). > Also it makes call to perform_spin_delay a bit slower, that could > positively a

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Hi, On 2017-06-05 16:22:58 +0300, Sokolov Yura wrote: > Patch changes the way LWLock is acquired. > > Before patch, lock is acquired using following procedure: > 1. first LWLock->state is checked for ability to take a lock, and CAS > performed (either lock could be acquired or not). And it is

Re: [HACKERS] [POC] Faster processing at Gather node

void iterating > >over all workers. > > I don't follow. Well, right now we're busily checking each worker's queue. That's fine with a handful of workers, but starts to become not that cheap pretty soon afterwards. In the surely common case where the workers are the bottleneck (

Re: [HACKERS] [POC] Faster processing at Gather node

Hi, On 2017-10-17 14:39:57 -0700, Andres Freund wrote: > I've spent some time looking into this, and I'm not quite convinced this > is the right approach. Let me start by describing where I see the > current performance problems around gather stemming from. One further approach t

Re: [HACKERS] [POC] Faster processing at Gather node

tructural issues, instead opting to address them by adding another layer of queuing. I suspect that if we'd go for the above solutions there'd be only very small benefit in implementing such per-worker local queues. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Windows warnings from VS 2017

ery compiler does so). I assume we probably should do this dance not just for palloc, but for the other allocation functions too. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [POC] Faster processing at Gather node

Hi Rafia, On 2017-05-19 17:25:38 +0530, Rafia Sabih wrote: > head: > explain analyse select * from t where i < 3000; > QUERY PLAN Could you share how exactly you generated the data? Just so others can compare a bit better with your

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

On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote: > On 9/20/17 04:32, Andres Freund wrote: > > Here's what I roughly was thinking of. I don't quite like the name, and > > the way the version is specified for libpq (basically just the "raw" > > integer). >

Re: [HACKERS] Aggregate FILTER option is broken in v10

ich seems like a pretty minimal extra cost for the normal case > with no filter. Thanks, that looks like a reasonable fix. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_control_recovery() return value when not in recovery

On 2017-10-13 16:31:37 -0700, Joe Conway wrote: > On 09/17/2017 11:29 PM, Andres Freund wrote: > > On 2017-09-18 07:24:43 +0100, Simon Riggs wrote: > >> On 18 September 2017 at 05:50, Andres Freund <and...@anarazel.de> wrote: > >> > Hi, > >&g

Re: [HACKERS] Disable cross products in postgres

On 2017-10-14 03:49:57 +0530, Gourav Kumar wrote: > But then is there some way to tell Optimizer not to consider transitive > joins ? What are you actually trying to achieve here? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Discussion on missing optimizations

years back. > It looks like there's plenty we could do in there, just nobody seems > interested enough to go and do it, everyone who cares about > performance is too busy trying to make execution run faster. I think that's largely because our executor speed is quite bad. To some degree because we

Re: [HACKERS] Improve catcache/syscache performance.

Hi, On 2017-10-13 10:38:47 -0700, Andres Freund wrote: > On 2017-10-13 13:06:41 -0400, Robert Haas wrote: > > On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund <and...@anarazel.de> wrote: > > > This patch gives me roughly 8% speedup in a workload that consists out > >

Re: [HACKERS] Improve catcache/syscache performance.

r type function lookups, oids, should be fairly easy in contrast. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Improve catcache/syscache performance.

Hi, On 2017-10-13 13:06:41 -0400, Robert Haas wrote: > On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund <and...@anarazel.de> wrote: > > This patch gives me roughly 8% speedup in a workload that consists out > > of a fast query that returns a lot of columns. If I apply a few

Re: [HACKERS] Continuous integration on Windows?

ed 00:04:36.37" I'd expected building would take a lot longer than that... Neat. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 17:27:52 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund <and...@anarazel.de> wrote: > >> In other words, it's not utterly fixed in stone --- we invented > >> --load-via-partition-root primarily to cope with circumstances that &g

Re: [HACKERS] show precise repos version for dev builds?

on > each rebuild, even if not necessary, though. That'd be quite painful, consider e.g. people using LTO. If done right however, that should be avoidable to some degree. When creating the version file, only replace its contents if the contents differ - that's just a few lines of scripting. Greeti

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 16:06:11 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 3:43 PM, Andres Freund <and...@anarazel.de> wrote: > > Are we going to rely on the the combine function to stay the same > > forever after? > > If we change them, it will be a pg_upgrade compa

Re: [HACKERS] [POC] hash partitioning

widths are fairly random, but they should bring in enough bit perturbation when mixing in only 32bit of hash value (i.e 0x0000). Are we going to rely on the the combine function to stay the same forever after? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

On 2017-10-11 21:59:53 -0700, Andres Freund wrote: > That fixed that problem I think. But unfortunately since then another > problem has been reported by some other animals, all with older msvc > versions afaict (thrips - vs 2012, bowerbird - vs 2012). Correction, thrips is vs 2010,

[HACKERS] Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

On 2017-10-11 17:13:20 -0700, Andres Freund wrote: > Hi, > > On 2017-10-11 23:11:15 +0000, Andres Freund wrote: > > Add configure infrastructure to detect support for C99's restrict. > > > > Will be used in later commits improving performance for a few key > >

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On 2017-10-11 08:54:10 -0700, Andres Freund wrote: > On 2017-10-11 10:53:56 +0200, Alvaro Herrera wrote: > > Maybe it'd be a good idea to push 0001 with some user of restrict ahead > > of the rest, just to see how older msvc reacts. > > Can do. Not quite sure which older use

Re: [HACKERS] Windows warnings from VS 2017

> On 09/21/2017 09:41 PM, Andres Freund wrote: > > On 2017-09-21 09:30:31 -0400, Tom Lane wrote: > >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > >>> The speed of memset is hardly going to be the dominating factor in a > >>> 'CREATE

Re: [HACKERS] Re: [BUGS] BUG #14821: idle_in_transaction_session_timeout sometimes gets ignored when statement timeout is pending

nything when it gets called > because the query cancel holdoff counter is positive. > > Andres suggested the following re-ordering of the logic on -bugs: I've pushed this. Thanks for the report & fix! Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

iterally allocate 1kb to send a single four byte integer. Fixing the output function performance requires a fairly different type of patch imo. > If do nothing, it's unlikely we'd ever get rid of the compat function. I think that's ok. Greetings, Andres Freund -- Sent via pgsql-hac

Re: [HACKERS] Slow synchronous logical replication

. There should be one. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

On 2017-10-11 10:53:56 +0200, Alvaro Herrera wrote: > Andres Freund wrote: > > Hi, > > > > On 2017-10-03 13:58:37 -0400, Robert Haas wrote: > > > On Tue, Oct 3, 2017 at 12:23 PM, Andres Freund <and...@anarazel.de> wrote: > > > > Makes sense? >

Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with a lot of columns

Hi, On 2017-10-03 13:58:37 -0400, Robert Haas wrote: > On Tue, Oct 3, 2017 at 12:23 PM, Andres Freund <and...@anarazel.de> wrote: > > Makes sense? > > Yes. Here's an updated version of this patchset. Changes: - renamed pq_send$type_pre to pq_write*type - rename

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

well. > > > > Why? Note that we don't do elsehwere in fe-connect.c. > > Because it seems to me that the default value of the parameter should > be an empty string instead of D. Feels more consistent with the > others. I'm not following. The "D" is in the 'disp

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

Hi, On 2017-10-11 10:09:34 +0900, Michael Paquier wrote: > On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-09-20 01:32:36 -0700, Andres Freund wrote: > >> Coverage of the relevant files is a good bit higher afterwards. Although

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

On 2017-09-20 01:32:36 -0700, Andres Freund wrote: > On 2017-09-18 02:53:03 -0700, Andres Freund wrote: > > On 2017-09-13 23:39:21 -0400, Tom Lane wrote: > > > The real problem in this area, to my mind, is that we're not testing that > > > code --- either end of i

Re: [HACKERS] Latches API on windows

On October 9, 2017 6:56:10 AM PDT, Tom Lane wrote: >Craig Ringer writes: >> On 9 October 2017 at 21:26, Abbas Butt >wrote: >>> In my case this is not true, I am calling InitSharedLatch in >_PG_init >>> which gets called

Re: [HACKERS] Discussion on missing optimizations

On 2017-10-08 17:11:44 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-10-08 11:28:09 -0400, Tom Lane wrote: > >> https://commitfest.postgresql.org/15/1001/ > >> The reason that's not in v10 is we haven't been able to convinc

Re: [HACKERS] is possible cache tupledesc templates in execution plan? significant performance issue, maybe bug?

On 2017-10-08 18:57:28 +0200, Pavel Stehule wrote: > 2017-10-08 18:44 GMT+02:00 Andres Freund <and...@anarazel.de>: > > > Hi, > > > > On 2017-10-08 18:36:23 +0200, Pavel Stehule wrote: > > > 2. Lot of used tables are pretty wide - 60, 120, .. columns >

Re: [HACKERS] is possible cache tupledesc templates in execution plan? significant performance issue, maybe bug?

st "optimization". > 2. If is not possible to reduce the number of fields of target list, is > possible to store tupledesc template to plan? We should do that, but it's not a small change. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Discussion on missing optimizations

it won't help in this specific case (no support for UNION, just UNION ALL), but I thought it might be interesting to reference https://medium.com/@uwdb/introducing-cosette-527898504bd6 here. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] Slow synchronous logical replication

nt and are there > some plans to work in this direction? This seems to be a question that is a) about a commercial project we don't know much about b) hasn't received a lot of investigation. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Discussion on missing optimizations

of sorting the lists. Sorting them would be beneficial for other reasons as well, e.g. it improves access patterns for SAO index scans. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Discussion on missing optimizations

Sets 8. CHECK Constraints I think some of this should actually work with constraint exclusion turned on. 9. Unneeded Self JOIN Can't remember discussions of this. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] valgrind complains about WaitEventSetWaitBlock on HEAD (fe9ba28e)

, but this does not look normal, > hence this post. I think this might be more a valgrind bug than anything. Note the "sigmask points to to unaddressable byte" and "Address 0x0 is not stack'd, malloc'd or (recently) free'd" bits. It's valid to pass a NULL sigmask argument.

Re: [HACKERS] fork()-safety, thread-safety

On October 5, 2017 5:15:41 PM PDT, Tom Lane <t...@sss.pgh.pa.us> wrote: >Andres Freund <and...@anarazel.de> writes: >> On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: >>> The only thing that gets me excited about a threaded postgres is the >>> ability to

Re: [HACKERS] fork()-safety, thread-safety

On 2017-10-06 07:59:40 +0800, Craig Ringer wrote: > The only thing that gets me excited about a threaded postgres is the > ability to have a PL/Java, PL/Mono etc that don't suck. We could do > some really cool things that just aren't practical right now. Faster parallelism with a lot less

Re: [HACKERS] fork()-safety, thread-safety

On 2017-10-05 18:49:22 -0400, Tom Lane wrote: > (There's certainly an argument to be made that no-one cares about > platforms without thread support anymore. But I'm unconvinced that > rewriting existing code that works fine is the most productive > way to exploit such a choice if we were to make

Re: [HACKERS] fork()-safety, thread-safety

ards threads, but not at all for > > the reasons mentioned here. > > You don't think eliminating a large difference between handling of WIN32 > vs. POSIX is a good reason? I seems like you'd not really get a much reduced set of differences, just a *different* set of differences.

Re: [HACKERS] fork()-safety, thread-safety

gt;since no page copying (COW or otherwise) needs be done when using >vfork(). Not on linux, at least not as of a year or two back. I do think it'd be good to move more towards threads, but not at all for the reasons mentioned here. Greetings, Andres Freund -- Sent via pgsql

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

ction with > CREATE FUNCTION, and having it in a separate array shouldn't hurt those > lookups. When'd that be beneficial? fmgr_builtins is pretty much only used for internal-language CREATE FUNCTIONs? In other cases oid bounds + mapping array should filter out the access before fmgr_builtins is acces

Re: [HACKERS] JIT compiling - v4.0

On 2017-10-05 23:43:37 +1300, David Rowley wrote: > On 5 October 2017 at 19:57, Andres Freund <and...@anarazel.de> wrote: > > Here's some numbers for a a TPC-H scale 5 run. Obviously the Q01 numbers > > are pretty nice in partcular. But it's also visible that the shorter >

Re: [HACKERS] JIT compiling - v4.0

On 2017-10-04 11:56:47 +0300, Ants Aasma wrote: > On Wed, Oct 4, 2017 at 9:48 AM, Andres Freund <and...@anarazel.de> wrote: > > Here's an updated version of the patchset. There's some substantial > > changes here, but it's still very obviously very far from committable as

[HACKERS] Re: [BUGS] Re: [PATCH] BUG #13416: Postgres >= 9.3 doesn't use optimized shared memory on Solaris anymore

imits on solaris based stuff as it does on linux etc? I think if we want to do this, we should rather go with a patch like https://www.postgresql.org/message-id/20140422121921.gd4...@awork2.anarazel.de Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-10-02 15:01:36 -0700, Andres Freund wrote: > On 2017-10-02 17:57:51 -0400, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > Done that way. It's a bit annoying, because we've to take care to > > > initialize the "unused" par

Re: [HACKERS] JIT compiling - v4.0

s solely via the git tree, rather than full reposts. Greetings, Andres Freund 0001-Rely-on-executor-utils-to-build-targetlist-for-DM.v4.patch.gz Description: application/patch-gzip 0002-WIP-Allow-tupleslots-to-have-a-fixed-tupledesc-us.v4.patch.gz Description: application/patch-gzip 0003-P

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

storing them in the a dshash table instead of dynahash? Similar to how we're now dealing with the shared typmod registry stuff? It should be fairly simple to now simply add a new struct Session member shared_enum_whatevs_table. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

Hi, On 2017-10-03 16:34:38 -0400, Andrew Dunstan wrote: > On 10/03/2017 03:00 PM, Andres Freund wrote: > > Hi, > > > > In my llvm jit work I'd to > > > > #undef PM > > /* include some llvm headers */ > > #define PM 1 > > > > because llvm

  1   2   3   4   5   6   7   8   9   10   >