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
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
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
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
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
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
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
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
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);
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
>> >
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 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
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
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
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
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
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
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
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 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
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
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
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)
; * 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-
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
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
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
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
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
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
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
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 (
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
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
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
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
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).
>
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
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
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
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
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
> >
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
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
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
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
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
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
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
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,
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
> >
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
> 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
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
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
. 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
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?
>
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
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
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
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
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
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
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
>
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
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
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
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
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
, 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.
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
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
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
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.
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
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
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
>
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
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.
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
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
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
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 - 100 of 8944 matches
Mail list logo