On 05/06/2015 09:51 PM, Heikki Linnakangas wrote:
So, yes, DO NOTHING does very little - and that is its appeal.
Supporting this behavior does not short change those who actually care
about the existing tuple sticking around for the duration of their
transaction - they have a way of doing that.
On 05/05/2015 01:10 PM, Emre Hasegeli wrote:
I already replied his email [1]. Which issues do you mean?
Sorry, my bad please ignore the previous email.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 05/05/2015 11:57 AM, Emre Hasegeli wrote:
From my point of view as a reviewer this patch set is very close to being
committable.
Thank you. The new versions are attached.
Nice, I think it is ready now other than the issues Alvaro raised in his
review[1]. Have you given those any
On 05/05/2015 04:24 AM, Alvaro Herrera wrote:
Stefan Keller wrote:
I'm keen to see if a PostGIS specialist jumps in and adds PostGIS
geometry support.
Did you test the patch proposed here already? It could be a very good
contribution.
Indeed, I have done some testing of the patch but more
.
- Missing space in except box and point*/.
- Otherwise looks good.
= brin-inclusion-v06-07-remove-minmax-amprocs.patch
Shouldn't this be merged with 02? Otherwise it looks good.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
with Alvaro's comments.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 04/05/2015 05:56 PM, Simon Riggs wrote:
Committed. We move forwards, slowly but surely. Thanks for the patch.
Thanks to you and the reviewers for helping me out with this patch!
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi,
The pg_amproc functions for inet_gist were accidentally added under the
gin heading. I have attached a patch which moves them to the gist
heading where they belong.
--
Andreas Karlsson
diff --git a/src/include/catalog/pg_amproc.h b/src/include/catalog/pg_amproc.h
index 8a43f64..78c3bd9
On 03/28/2015 09:36 PM, Andreas Karlsson wrote:
Thanks! Do you know if it is possible to add index-only scan support to
range indexes? I have never looked at those and do not know if they are
lossy.
Seems like range types are not compressed at all so implementing
index-only scans was trivial
On 03/29/2015 03:25 AM, Andreas Karlsson wrote:
On 03/28/2015 09:36 PM, Andreas Karlsson wrote:
Thanks! Do you know if it is possible to add index-only scan support to
range indexes? I have never looked at those and do not know if they are
lossy.
Seems like range types are not compressed
On 03/28/2015 02:12 PM, Heikki Linnakangas wrote:
Looks good to me. Committed, thanks.
Thanks! Do you know if it is possible to add index-only scan support to
range indexes? I have never looked at those and do not know if they are
lossy.
Andreas
--
Sent via pgsql-hackers mailing list
, but wanted to let people know I'm working on this.
Would it also be worth doing the same for the inet_ops class for
inet/cidr? I have hacked a quick WIP patch which I believe should work,
but have not looked into the index only scan code enough to be sure.
--
Andreas Karlsson
diff --git a/src
On 03/22/2015 11:47 AM, Petr Jelinek wrote:
On 22/03/15 10:35, Andres Freund wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacanadt=2015-03-21%2003%3A01%3A21
That's the stuff looking like random memory that I talk about above...
If you look at it closely, it's actually not
On 03/22/2015 10:20 PM, Andres Freund wrote:
Yes, or a compiler bug. I looked through the code again and found and
fixed one minor bug, but that doesnt' explain the problem.
Strangely enough the bug looks like it has been fixed at jacana after
your fix of my copypasto. Maybe the bug is
satisfied with how the patch looks. Thanks for your work. I
will mark this as ready for committeer now but not expect any committer
to look at it until the commitfest starts.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 03/20/2015 10:32 AM, Andres Freund wrote:
Pushed with that additional change. Let's see if the buildfarm thinks.
Thanks for the feature.
Thanks to you and all the reviewers for helping me out with it.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 03/19/2015 04:55 PM, Julien Tachoires wrote:
On 18/03/2015 19:54, Andreas Karlsson wrote:
Looks good but I think one minor improvement could be to set the table
space of the toast entires to the same as the tablespace of the table to
reduce the amount of SET default_tablespace. What do you
.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
as the tablespace of the table to
reduce the amount of SET default_tablespace. What do you think?
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in the final commit when autoconf tests are
added, mostly because I do not have the exact version of autoconf on
my development machine required to do this without creating irrelevant
Thanks,
I have attached a patch where I have ran autoconf.
--
Andreas Karlsson
diff --git a/config/c-compiler.m4 b
for committer?
New version with altered comment is attached.
--
Andreas Karlsson
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 509f961..48fcc68 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -125,6 +125,41 @@ undefine([Ac_cachevar])dnl
])# PGAC_TYPE_64BIT_INT
On 03/15/2015 04:25 AM, Andreas Karlsson wrote:
Nice. You will also want to apply the attached patch which fixes support
for the --no-tablespaces flag.
Just realized that --no-tablespaces need to be fixed for pg_restore too.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql
On 03/14/2015 05:59 PM, Julien Tachoires wrote:
On 14/03/2015 16:10, Andreas Karlsson wrote:
Noticed a bug when playing round some more with pg_dump. It does not
seem to dump custom table space for the table and default table space
for the toast correctly. It forgets about the toast table being
for
committer, but since it is in the open commitfest I do not think it will
get committed any time soon.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Noticed a bug when playing round some more with pg_dump. It does not
seem to dump custom table space for the table and default table space
for the toast correctly. It forgets about the toast table being in
pg_default.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 03/13/2015 10:22 PM, Peter Geoghegan wrote:
On Thu, Mar 12, 2015 at 6:23 PM, Andreas Karlsson andr...@proxel.se wrote:
/*
* Integer data types use Numeric accumulators to share code and avoid risk
* of overflow. To speed up aggregation 128-bit integer accumulators are
* used instead
On 03/10/2015 01:23 PM, Robert Haas wrote:
On Mon, Mar 9, 2015 at 7:26 PM, Andreas Karlsson andr...@proxel.se wrote:
- I do not like how \d handles the toast tablespace. Having TOAST in
pg_default and the table in another space looks the same as if there was
no TOAST table at all. I think we
On 03/07/2015 07:18 PM, Petr Jelinek wrote:
What I am wondering is if those numeric_int16_* functions that also deal
with either the Int128AggState or NumericAggState should be renamed in
similar fashion.
You mean something like numeric_poly_sum instead of numeric_int16_sum? I
personally am
On 03/03/2015 04:14 PM, Julien Tachoires wrote:
On 30/12/2014 03:48, Andreas Karlsson wrote:
- A test fails in create_view.out. I looked some into it and did not see
how this could happen.
[...]
I can't reproduce this issue.
Neither can I anymore.
- pg_dump is broken
pg_dump
numeric_int16_* to numeric_poly_*
- Rename static functions int{8,16}_to_numericvar to
int{64,128}_to_numericvar
- Fix typo in c-compile.m4 comment
--
Andreas Karlsson
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 509f961..48fcc68 100644
--- a/config/c-compiler.m4
+++ b/config/c
On 03/08/2015 08:14 PM, Dmitry Voronin wrote:
What do you think about it?
Nice to see you back working on the patch.
For reviewers: the previous discussion and review of the patch can be
found at http://www.postgresql.org/message-id/53a88911.6060...@proxel.se.
--
Andreas Karlsson
--
Sent
On 03/03/2015 04:14 PM, Julien Tachoires wrote:
Sorry for the delay, I missed this thread.
Here is a new version of this patch considering Andreas' comments.
Please also add it to the next open commitfest so we do not lose the patch.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing
random spaces in select numrange(1.0, 2.0) + numrange(2.5,
3.0);-- should fail
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/29/2015 12:28 AM, Peter Geoghegan wrote:
On Mon, Jan 26, 2015 at 11:21 PM, Andreas Karlsson andr...@proxel.se wrote:
Do you also think the SQL functions should be named numeric_int128_sum,
numeric_int128_avg, etc?
Some quick review comments. These apply to int128-agg-v5.patch.
* Why
of the AC_LANG_* macros they were easy to remove.
--
Andreas Karlsson
From 16749732d28a027f0704784eaf180ed916c8511f Mon Sep 17 00:00:00 2001
From: Andreas Karlsson andr...@proxel.se
Date: Thu, 12 Feb 2015 23:55:01 +0100
Subject: [PATCH 1/4] Replace obsolete macros AC_TRY_* with AC_*_IFELSE
On 02/13/2015 02:07 PM, Michael Paquier wrote:
Andreas, are you planning to continue working on this patch? Peter has
provided some comments that are still unanswered.
Yes, but I am quite busy right now. I will try to find time some time
later this week.
--
Andreas Karlsson
--
Sent via
On 02/06/2015 08:16 AM, Michael Paquier wrote:
On Fri, Jan 30, 2015 at 10:26 PM, Andreas Karlsson wrote:
On 01/30/2015 07:48 AM, Michael Paquier wrote:
Looking at the latest patch, it seems that in
AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
AT_AddConstraintRecurse
as they are still on
the website.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/30/2015 07:48 AM, Michael Paquier wrote:
Ok, so the deal is to finally reduce the locks to
ShareRowExclusiveLock for the following commands :
- CREATE TRIGGER
- ALTER TABLE ENABLE/DISABLE
- ALTER TABLE ADD CONSTRAINT
Correct. I personally still find this useful enough to justify a patch.
On 01/27/2015 09:05 AM, Andres Freund wrote:
On 2015-01-27 08:21:57 +0100, Andreas Karlsson wrote:
On 01/23/2015 02:58 AM, Petr Jelinek wrote:
On 23/01/15 00:40, Andreas Karlsson wrote:
- Renamed some things from int12 to int128, there are still some places
with int16 which I am not sure what
On 01/23/2015 02:58 AM, Petr Jelinek wrote:
On 23/01/15 00:40, Andreas Karlsson wrote:
- Renamed some things from int12 to int128, there are still some places
with int16 which I am not sure what to do with.
I'd vote for renaming them to int128 too, there is enough C functions
that user int16
.
--
Andreas Karlsson
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index a0d6867..fc86224 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -908,9 +908,9 @@ ERROR: could not serialize access due to read/write dependencies among transact
/para
para
, there are still some places
with int16 which I am not sure what to do with.
A remaining issue is what estimate we should pick for the size of the
aggregate state. This patch uses the size of the int128 version for the
estimate, but I have no strong opinions on which we should use.
--
Andreas
`__int128_t'. */
+#undef HAVE___INT128_T
+
+/* Define to 1 if the system has the type `__uint128_t'. */
+#undef HAVE___UINT128_T
pg_config.h.win32 should be updated as well.
Will be fixed in the next version.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
with Robert about that we should just pick one estimate and
use that. I picked the smaller one, but that might be too optimistic so
feel free to ask me to switch it back or to pick something in between
the two estimates.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 01/16/2015 03:01 PM, Andres Freund wrote:
Hi,
/*
-* Grab an exclusive lock on the pk table, so that someone doesn't
delete
-* rows out from under us. (Although a lesser lock would do for that
-* purpose, we'll need exclusive lock anyway to add triggers to
On 01/14/2015 08:48 AM, Michael Paquier wrote:
All those things gathered give the patch attached. Andreas, if you are
fine with it I think that we could pass it to a committer.
Excellent changes. Thanks for the patch and the reviews.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing
opclasses
is the way to go, not a generic one as I am trying.
I think a STORAGE parameter sounds like a good idea. Could it also be
used to solve the issue with IPv4/IPv6 by setting the storage type to
custom? Or is that the wrong way to fix things?
--
Andreas Karlsson
--
Sent via pgsql-hackers
not feel like having two ifdef blocks. I have no strong opinion about
this though.
pg_config.h.win32 should be updated as well.
Is it possible to update it without running Windows?
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
lock levels was safe, which Robert,
Tom and others were slightly uncertain about.
Is there anything different here from work in my original patch series?
As far as I know, no.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
git
format which is what I am more used to work with.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
than adding an
ifdef I am not totally sure if this difference is real.
master
tps = 1.001984 (excluding connections establishing)
Without int128
tps = 1.014511 (excluding connections establishing)
With int128
tps = 3.185956 (excluding connections establishing)
--
Andreas Karlsson
diff --git
the CONCURRENTLY case.
By the way, unless I am mistaken there is currently no protection
against having a concurrent ALTER FUNCTION ... RENAME mess up what is
dumped in by pg_get_triggerdef().
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
I have attached a patch with the current status of my work on reducing
the lock level of trigger and foreign key related DDL.
This commit reduces the lock level of the following commands from ACCESS
EXCLUSIVE to SHARE ROW EXCLUSIVE, plus that it does the same for the
referred table of
On 11/20/2014 01:52 AM, Peter Geoghegan wrote:
On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan p...@heroku.com wrote:
Also, I think someone else mentioned this a few months back.
Yeah, that was me.
I think we have three options.
1. Return only inserted tuples
2. Return inserted and updated
On 11/13/2014 03:38 AM, Alvaro Herrera wrote:
configure is a generated file. If your patch touches it but not
configure.in, there is a problem.
Thanks for pointing it out, I have now fixed it.
--
Andreas Karlsson
diff --git a/configure b/configure
new file mode 100755
index c4f70e8..bb801b4
Windows machines either.
A couple of things I was not sure about was the naming of the new
functions and if I should ifdef the size of the aggregate state in the
catalog or not.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 11/13/2014 02:03 AM, Andreas Karlsson wrote:
Here is version 2 of the patch which detects the presence of gcc/clang
style 128-bit integers and has been cleaned up to a reviewable state. I
have not added support for any other compilers since I found no
documentation 128-bit support with icc
On 11/07/2014 08:15 AM, Simon Riggs wrote:
How about we set lock level on each Foreign Key like this
[USING LOCK [lock level]]
level is one of
KEY - [FOR KEY SHARE] - default
ROW - [FOR SHARE]
TABLE SHARE - [ ]
TABLE EXCLUSIVE - [FOR TABLE EXCLUSIVE]
I like the idea and thinks it solves the
On 11/06/2014 02:30 AM, Peter Geoghegan wrote:
Thanks for the review.
On Wed, Nov 5, 2014 at 4:33 PM, Andreas Karlsson andr...@proxel.se wrote:
I looked at the changes to the code. The new code is clean and there is more
code re-use and improved readability. On possible further improvement
in tuplesort_begin_index_btree()
before /* Prepare SortSupport data for each column */.
- Remove the extra newline after reversedirection().
- End sentences in comments with period. That seems to be the common
practice in the project.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 11/02/2014 06:41 PM, Tom Lane wrote:
I wrote:
Either way, requiring a dump/reload for upgrade is surely a better answer
for users of the type than just summarily screwing them.
BTW, after reflecting a bit more I'm less than convinced that this
datatype is completely useless. Even if you
On 10/28/2014 02:05 PM, Arthur Silva wrote:
As far as I'm aware int128 types are supported on every major compiler
when compiling for 64bit platforms. Right?
Both gcc and clang support __int128_t, but I do not know about other
compilers like icc and MSVC.
Andreas
--
Sent via
On 10/28/2014 03:40 PM, Heikki Linnakangas wrote:
The patch doesn't do division with the 128-bit integers. It only does
addition and multiplication. Those are pretty straightforward to implement.
The patch uses division when converting from __int128_t to Numeric.
- Andreas
--
Sent via
On 10/28/2014 04:01 PM, Heikki Linnakangas wrote:
Moving on to other issues, isn't 128 bits too small to store the squares
of the processed numbers? That could overflow..
Yeah, which is why stddev_*(int8) and var_*(int8) still have to use
Numeric in the aggregate state. For the int2 and int4
would take row
locks).
This is just a dream scenario though, and focusing on triggers is indeed
the reasonable goal for 9.5.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Hi,
There was recently talk about if we should start using 128-bit integers
(where available) to speed up the aggregate functions over integers
which uses numeric for their internal state. So I hacked together a
patch for this to see what the performance gain would be.
Previous thread:
On 10/22/2014 04:13 PM, Tom Lane wrote:
Andreas Karlsson andr...@proxel.se writes:
I have attached a proof of concept
patch which reduces the lock strength to ShareLock.
You're kidding, right? ShareLock isn't even self-exclusive.
Why would it have to be self-exclusive? As far as I know we
Hi,
I have been thinking about why we need to grab an AccessExclusiveLock on
the table with the PK when we add a foreign key. Adding new tables with
foreign keys to old ones is common so it would be really nice if the
lock strength could be reduced.
A comment in the code claims that we need
On 09/28/2014 09:40 AM, Peter Geoghegan wrote:
No explanation of why the CONFLICTING() syntax differs from OLD./NEW.
syntax used in triggers
Why should it be the same?
Both can be seen as cases where you refer to a field of a tuple, which
is usually done with FOO.bar.
--
Andreas Karlsson
were returned but there
was some way to filter out only the inserted ones.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/28/2014 09:05 PM, Peter Geoghegan wrote:
On Thu, Aug 28, 2014 at 7:29 AM, Andreas Karlsson andr...@proxel.se wrote:
Personally I would find it surprising if RETURNING did not also return the
updated tuples. In many use cases for upsert the user does not care if the
row was new
() is implemented using pg_do_encoding_conversion().
I don't write a code of those functions and I can't answer on your question.
Hm, I thought I saw them changed from static to not in the diff after
applying your patch. Maybe I just misread the patch.
--
Andreas Karlsson
--
Sent via pgsql-hackers
pass now on my
Debian machine.
One thing I noticed when trying to find the bug is that be-secure.c
still includes some OpenSSL headers. Those should be removed since they
have already been moved to be-secure-openssl.c.
--
Andreas Karlsson
diff --git a/src/backend/libpq/be-secure.c b/src
the Returns X datum comments look redundant to me, but this is a
matter of preference.
- The star when declaring result in ssl_get_extension_names() should be
put on the other side of the white space.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
' to 'Query_for_trigger_of_table' to hide them.
Good suggestion. I have attached a patch which filters out the internal
triggers, both for ALTER TABLE and DROP TRIGGER. I am not entirely sure
about the DROP TRIGGER case but I think I prefer no auto completion of
RI triggers.
--
Andreas Karlsson
diff
On 06/18/2014 02:34 AM, Ian Barwick wrote:
On 14/06/18 7:51, Andreas Karlsson wrote:
On 06/17/2014 01:36 PM, Ian Barwick wrote:
One issue - the table's internal triggers will also be listed. which can
result in
something like this:
This is a bit of an extreme case, but I don't think manually
On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
Thoughts? While we're at it, we'll probably want to refactor things so
that it's easy to support other SSL implementations too, like gnutls.
There was a patch set for this from Martijn van Oosterhout which was
quite complete.
is almost identical.
--
Andreas Karlsson
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 6d26ffc..65483de
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*** static const SchemaQuery Query_for_list_
*** 626,631
On 04/27/2014 07:07 PM, Tom Lane wrote:
Rewrite timing could easily be captured by EXPLAIN since that call
is done within ExplainQuery(). Parse analysis isn't, but we could
imagine having transformExplainStmt() time the operation and stick
the result into a new field in struct ExplainStmt.
I'm
On 04/17/2014 01:35 AM, Tom Lane wrote:
I'll go change it.
Thanks for fixing this. The new name Execution time is much clearer.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On 04/04/2014 04:01 PM, Andres Freund wrote:
This patch looks like it can be applied much more realistically, but it
looks too late for 9.4. I suggest moving it to the next CF?
If it does not change the default operator class I do not see anything
preventing it from being applied to 9.4, as
On 03/08/2014 10:40 PM, Emre Hasegeli wrote:
Fourth version of the patch attached. It is rebased to the HEAD (8879fa0).
Operator name formatting patch rebased on top of it. I will put
the selectivity estimation patch to the next commit fest.
This version of the patch does not touch to the
. pg_receivexlog must be started with postmaster and
monitored with some measures. This won't be very easy at least on Windows.
Replication slots should solve the issue of making sure to catch all of
the WAL.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers
!
Do you think the new index is useful even if you use the basic
geo_selfuncs? Or should we wait with committing the patches until all
selfuncs are implemented?
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
is your plan for this?
--
Andreas Karlsson
diff --git a/src/backend/utils/adt/network_selfuncs.c b/src/backend/utils/adt/network_selfuncs.c
new file mode 100644
index 87a7390..3b99afe
*** a/src/backend/utils/adt/network_selfuncs.c
--- b/src/backend/utils/adt/network_selfuncs.c
On 01/28/2014 09:39 PM, Tom Lane wrote:
I'm for doing the measurement in ExplainOneQuery() and not printing
anything in code paths that don't go through there.
Reading the discussion here and realizing that my last patch was wrong I
am now in agreement with this. I have attached a patch which
On 01/29/2014 09:01 PM, Robert Haas wrote:
Cool. I propose adding one parameter rather than two to
ExplainOnePlan() and making it of type instr_time * rather than
passing an instr_time and a bool. If you don't want to include the
planning time, pass NULL; if you do, pass a pointer to the
On 01/29/2014 10:10 PM, Robert Haas wrote:
Committed with minor doc changes.
Thanks!
/Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
backup and logical backup, for example on Barman's
homepage.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
actually planned a query. I do not really like how I check for
if it was replanned, but I tried to avoid making changes in plancache.c.
Does this idea look ok?
--
Andreas Karlsson
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
new file mode 100644
index 2af1738..482490b
than using geo_selfuncs.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
DEFAULT_NETWORK_OVERLAP_SELECTIVITY should be renamed
DEFAULT_NETWORK_OVERLAP_SEL and moved to the .c file.
Typo in comment, constrant - constant.
There is an extra empty line at the end of network_selfuncs.c
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
functions. They are named things like
tsmatchsel, tsmatchjoinsel, and rangesel.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/18/2014 08:13 PM, Jeremy Harris wrote:
On 31/12/13 01:41, Andreas Karlsson wrote:
On 12/29/2013 08:24 AM, David Rowley wrote:
If it was possible to devise some way to reuse any
previous tuplesortstate perhaps just inventing a reset method which
clears out tuples, then we could see
. If the consensus
is that we want to always measure it I will look at implementing that
instead.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
example
how this would look compared to your RETURNING REJECTS proposal?
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
when you feel it
is ready for a review.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/12/2014 11:20 PM, Peter Geoghegan wrote:
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson andr...@proxel.se wrote:
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which would see a DML statement
-SQL-assertions-prototype.patch.
Best regards,
Andreas
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
201 - 300 of 350 matches
Mail list logo
