Do you have any benchmarks ?
On Mon, Sep 23, 2013 at 3:38 AM, Stas Kelvich stas.kelv...@gmail.comwrote:
Hello, hackers.
Here is the patch that introduces kNN search for cubes with euclidean,
taxicab and chebyshev distances.
Following distance operators introduced:
# taxicab distance
-
At 2013-08-19 11:47:36 +, laurenz.a...@wien.gv.at wrote:
To repeat: this fixes a bug in LDAP connection parameter lookup
Hi.
I read through the patch, and it looks sensible.
I would have preferred the ldap_simple_bind_s() call in the HAVE_LIBLDAP
branch to not be inside an else {} (the if
From: Tatsuo Ishii is...@postgresql.org
I don't think the bind placeholder is the case. That is processed by
exec_bind_message() in postgres.c. It has enough info about the type
of the placeholder, and I think we can easily deal with NCHAR. Same
thing can be said to COPY case.
Yes, I've
I forgot about removal of the relevant SGML, amended here in v6.
Thank you for this!
i did a quick test with following steps:
1. Applied v6 patch
2. make and make install on pg_stat_statements;
3. Restarted Postgres with pg_stat_statements loaded with
pg_stat_statements.max = 4
4. Dropped and
On 2013-09-20 14:15:23 -0700, Peter Geoghegan wrote:
I have a little bit of feedback that I forgot to mention in my earlier
reviews, because I thought it was too trivial then: something about
the name pg_receivellog annoys me in a way that the name
pg_receivexlog does not. Specifically, it
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN boolean expression
RAISE ASSERT 'some message' WHEN expression
It looks like I'm losing this battle, but this syntax isn't too bad.
and we can
2013/9/23 Marko Tiikkaja ma...@joh.to
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN boolean expression
RAISE ASSERT 'some message' WHEN expression
It looks like I'm losing this battle,
On 9/23/13 10:50 AM, I wrote:
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN boolean expression
RAISE ASSERT 'some message' WHEN expression
It looks like I'm losing this battle, but this
On 23 September 2013 10:10, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/9/22 Jaime Casanova ja...@2ndquadrant.com
El 21/09/2013 17:16, Jaime Casanova ja...@2ndquadrant.com escribió:
On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja ma...@joh.to wrote:
On 9/20/13 12:09 PM, Amit
On 2013-09-23 11:00:50 +0200, Marko Tiikkaja wrote:
On 9/23/13 10:50 AM, I wrote:
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN boolean expression
RAISE ASSERT 'some message' WHEN
2013/9/23 Amit Khandekar amit.khande...@enterprisedb.com
On 23 September 2013 10:10, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/9/22 Jaime Casanova ja...@2ndquadrant.com
El 21/09/2013 17:16, Jaime Casanova ja...@2ndquadrant.com escribió:
On Fri, Sep 20, 2013 at 5:17 AM,
2013/9/23 Marko Tiikkaja ma...@joh.to
On 9/23/13 10:50 AM, I wrote:
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN boolean expression
RAISE ASSERT 'some message' WHEN expression
It
2013/9/23 Andres Freund and...@2ndquadrant.com
On 2013-09-23 11:00:50 +0200, Marko Tiikkaja wrote:
On 9/23/13 10:50 AM, I wrote:
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN
On 9/23/13 11:01 AM, Amit Khandekar wrote:
The assert levels sound a bit like a user might be confused by these levels
being present at both places: In the RAISE syntax itself, and the assert
GUC level. But I like the syntax. How about keeping the ASSERT keyword
optional ? When we have WHEN, we
On 9/23/13 11:12 AM, I wrote:
On 9/23/13 11:01 AM, Amit Khandekar wrote:
The assert levels sound a bit like a user might be confused by these levels
being present at both places: In the RAISE syntax itself, and the assert
GUC level. But I like the syntax. How about keeping the ASSERT keyword
2013/9/23 Marko Tiikkaja ma...@joh.to
On 9/23/13 11:12 AM, I wrote:
On 9/23/13 11:01 AM, Amit Khandekar wrote:
The assert levels sound a bit like a user might be confused by these
levels
being present at both places: In the RAISE syntax itself, and the assert
GUC level. But I like the
On 23 September 2013 14:33, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/9/23 Amit Khandekar amit.khande...@enterprisedb.com
On 23 September 2013 10:10, Pavel Stehule pavel.steh...@gmail.comwrote:
2013/9/22 Jaime Casanova ja...@2ndquadrant.com
El 21/09/2013 17:16, Jaime
On 06.06.2013 17:22, Robert Haas wrote:
On Thu, May 30, 2013 at 2:29 AM, Andres Freundand...@2ndquadrant.com wrote:
Yeah, I think it's fine. The patch also looks fine, although I think
the comments could use a bit of tidying. I guess we need to
back-patch this all the way back to 8.4? It
On 9/22/13 2:58 PM, Fabien wrote:
Split 3 of the initial submission, which actually deal with data
measured and reported on stderr under various options.
It seems this patch doesn't apply. Does it need the first two applied
first?
--
Sent via pgsql-hackers mailing list
On 2013-09-23 14:41:16 +0300, Heikki Linnakangas wrote:
On 06.06.2013 17:22, Robert Haas wrote:
On Thu, May 30, 2013 at 2:29 AM, Andres Freundand...@2ndquadrant.com
wrote:
Yeah, I think it's fine. The patch also looks fine, although I think
the comments could use a bit of tidying. I guess
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-23 14:41:16 +0300, Heikki Linnakangas wrote:
(spotted this while working on a patch, and ran into the assertion on
crash
recovery)
You got the assertion failure about CritSectionCount during recovery?
If so, I do not understand, that code
Dear Peter,
Split 3 of the initial submission, which actually deal with data
measured and reported on stderr under various options.
It seems this patch doesn't apply. Does it need the first two applied
first?
Oops. Indeed. The patch is fully independent of the two others. It was
Vesa-Matti J Kari,
I've now committed a fix for this issue. If you have opportunity to,
it'd be great to pull down the latest git (for whichever supported
branch you'd like) and give it a try. Otherwise, the fix should be
out with our next round of point releases (which I expect will be
On 09/19/2013 11:40 PM, Dimitri Fontaine wrote:
Vik Fearing vik.fear...@dalibo.com writes:
I don't know if this has been discussed before, a cursory search of the
archives didn't turn up anything interesting. I perhaps didn't put in
the right keywords.
For others not to spend too much time
I think the idea that we should consider a different way of handling
tabular configuration data has merit. In fact, how much sense does it
make to have these options (the ones for which this patch is being
written) be GUCs in the first place? ALTER USER/DATABASE don't work for
them, they can't
Daniel Farina escribió:
On Fri, Sep 20, 2013 at 1:11 AM, Daniel Farina dan...@fdr.io wrote:
I think the n-call underestimation propagation may not be quite precise for
various detailed reasons (having to do with 'sticky' queries) and to make it
precise is probably more work than it's worth.
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain ced...@2ndquadrant.com
wrote:
Andrew is about to commit (well...I hope) a doc patch about that and also a
little fix.
Imho this is a bugfix so I hope it will be applyed
On Sun, Sep 15, 2013 at 01:14:45PM +0400, Alexander Korotkov wrote:
On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
There's a few open questions:
1. How are we going to handle pg_upgrade? It would be nice to be able to
read the old page
Marti Raudsepp wrote:
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org wrote:
Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6
Improve support for building PGXS modules with VPATH fixes the
problem and I see it's not present in REL9_3_0.
Andrew and
On 09/23/2013 11:31 AM, Alvaro Herrera wrote:
Marti Raudsepp wrote:
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org wrote:
Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6
Improve support for building PGXS modules with VPATH fixes the
problem and I see it's not
On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
I think we should go through the various implementations and make sure
they are actual compiler barriers and then change the documented policy.
From a quick look
*
On 2013-09-23 11:50:05 -0400, Robert Haas wrote:
On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
I think we should go through the various implementations and make sure
they are actual compiler barriers and
On Mon, Sep 23, 2013 at 1:46 AM, Andres Freund and...@2ndquadrant.com wrote:
pg_receivelogical? Protest now or forever hold your peace.
I was thinking pg_receiveloglog, but that works just as well.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Le lundi 23 septembre 2013 11:43:13 Andrew Dunstan a écrit :
On 09/23/2013 11:31 AM, Alvaro Herrera wrote:
Marti Raudsepp wrote:
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp ma...@juffo.org
wrote:
Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6
Improve support for
On 2013-09-23 13:47:05 -0300, Alvaro Herrera wrote:
Andres Freund escribió:
On 2013-09-20 14:15:23 -0700, Peter Geoghegan wrote:
I have a little bit of feedback that I forgot to mention in my earlier
reviews, because I thought it was too trivial then: something about
the name
Just some notes, before I forget them again.
On 2013-09-23 11:50:05 -0400, Robert Haas wrote:
On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
I think we should go through the various implementations and make
Andres Freund escribió:
On 2013-09-20 14:15:23 -0700, Peter Geoghegan wrote:
I have a little bit of feedback that I forgot to mention in my earlier
reviews, because I thought it was too trivial then: something about
the name pg_receivellog annoys me in a way that the name
pg_receivexlog
On Mon, Sep 23, 2013 at 9:54 AM, Andres Freund and...@2ndquadrant.com wrote:
I still find it wierd/inconsistent to have:
* pg_receivexlog
* pg_recvlogical
binaries, even from the same source directory. Why once pg_recv and
once pg_receive?
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers
On Fri, Sep 20, 2013 at 11:23 AM, Stephen Frost sfr...@snowman.net wrote:
Perhaps I'm assuming things are farther along than they are.. I was
assumed that 'incremental mat view' updates were actuallly 'partial'-
iow, that it keeps track of the rows in the mat view which are
impacted by the
On Fri, Sep 20, 2013 at 11:28 PM, David Rowley dgrowle...@gmail.com wrote:\
I put the above results into the attached spreadsheet. On my intel i5 laptop
I'm seeing a slow down of about 1 second per million queries for the longer
log_line_prefix and about 1 second per 5 million queries with the
On Fri, Sep 20, 2013 at 4:26 PM, Mike Blackwell mike.blackw...@rrd.com wrote:
The file_fdw documentation for the OPTIONS clause references the COPY
command's documentation. In the case of COPY, the value for some options
(e.g. HEADER, OIDS, ...) is optional. While the file_fdw documentation
Andres Freund escribió:
On 2013-09-23 13:47:05 -0300, Alvaro Herrera wrote:
I had proposed pg_recvlogical
I still find it wierd/inconsistent to have:
* pg_receivexlog
* pg_recvlogical
binaries, even from the same source directory. Why once pg_recv and
once pg_receive?
Well. What are
* Robert Haas (robertmh...@gmail.com) wrote:
It seems odd to me that you have such strong opinions about what is
and is not acceptable here given that you don't seem to familiar with
the current state of this work.
That'd be because the arguments that I've been trying to make around
this
Robert,
Thanks for the reply. I have no objections to clarifying the note.
Attached is a patch with the text you suggested.
Mike
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management |
On Mon, Sep 23, 2013 at 1:19 PM, Stephen Frost sfr...@snowman.net wrote:
So I've gathered and I'm not terribly surprised that it's broken. It
was unfortunate that we committed it as such, imv. I'm *not* convinced
that means we should build on that in a direction that doesn't appear to
be
Stephen Frost sfr...@snowman.net wrote:
Robert Haas (robertmh...@gmail.com) wrote:
Now, the next project Kevin's going to work on, and that he was
working on when he discovered this problem, is incremental
maintenance: that is, allowing us to update the view *without*
needing to rerun the
On Mon, Sep 23, 2013 at 10:43:33AM +0530, Amit Kapila wrote:
On Mon, Sep 23, 2013 at 12:34 AM, Noah Misch n...@leadboat.com wrote:
On Sun, Sep 22, 2013 at 01:17:52PM +0530, Amit Kapila wrote:
#ifdef WIN32
/* use CRLF line endings on Windows */
_setmode(_fileno(fh), _O_TEXT);
#endif
On Mon, Sep 23, 2013 at 2:24 PM, Mike Blackwell mike.blackw...@rrd.com wrote:
Thanks for the reply. I have no objections to clarifying the note.
Attached is a patch with the text you suggested.
Committed, thanks. Per relatively-usual practice for doc
clarifications, I back-patched this one
* Kevin Grittner (kgri...@ymail.com) wrote:
Unless we can tell whether there are any differences between two
versions of a row, we can't accurately generate the delta to drive
the incremental maintenance.
This is predicated on the assumption that you simply generate the new
view and then try
On Mon, Sep 23, 2013 at 2:46 PM, Robert Haas robertmh...@gmail.com wrote:
Anyway, that is exactly what Kevin is proposing to do here and, to be
clear, he's NOT proposing to use the binary-identical semantics to
identify the row to be updated. That will happen using the semantics
of whatever
However this pattern induces stronger cache effects which are maybe not
too realistic,
because neighboring keys in the middle are more likely to be chosen.
I think that your opinion is right. However, in effect, it is a
paseudo-benchmark, so that I think that such a simple mechanism is also
You had accidentally added to the CF In Progress.
Oh, I had completely mistook this CF schedule :-)
Maybe, Horiguchi-san is same situation...
However, because of your moving, I become first submitter in next CF.
Thank you for moving :-)
--
Mitsumasa KONDO
On Sat, Sep 21, 2013 at 4:55 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
- Use progress option both under init bench.
Activate progress report by default, every 5 seconds.
When initializing, --quiet reverts to the old every 100,000 insertions
behavior...
Patch (1): Change the
Robert, all,
Skipping out on much of the side-discussion to try and drive at the
heart of this..
* Robert Haas (robertmh...@gmail.com) wrote:
I would suggest that you read the referenced papers for details as to
how the algorithm works. To make a long story short, they do need to
keep track
Stephen Frost sfr...@snowman.net wrote:
I'm trying to explain that using that methodology is what landed
us in this situation to begin with.
I'm trying to figure out what situation you think we're in.
Seriously, if you could apply the patch and show one example that
demonstrates what you see
On Fri, Sep 20, 2013 at 8:48 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Sep 17, 2013 at 9:29 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 14, 2013 at 6:27 PM, Peter Geoghegan p...@heroku.com wrote:
Note that today there is no guarantee that the original waiter for a
On Mon, Sep 23, 2013 at 3:45 PM, Stephen Frost sfr...@snowman.net wrote:
Robert, all,
Skipping out on much of the side-discussion to try and drive at the
heart of this..
* Robert Haas (robertmh...@gmail.com) wrote:
I would suggest that you read the referenced papers for details as to
how
On Sun, Sep 22, 2013 at 08:44:08PM +0200, Fabien COELHO wrote:
pgbench: minor update of documentation help message.
Use NUM in help message for homogeneity with other options. The target
*start* time of the transaction is set by the stochastic process which is
doing the throttling
On Tue, Sep 17, 2013 at 07:04:14PM +0500, Hamid Quddus Akhtar wrote:
In make check, there are 4 shared libraries that are loaded for test cases
from the src/test/regress folder. Whereas, output of other libraries
contain @libdir@ tag, the output file for security_label (dumm_seclabel)
contains
On Fri, Sep 20, 2013 at 8:32 PM, MauMau maumau...@gmail.com wrote:
I don't think that you'll be able to
get consensus around that path on this mailing list.
I agree that the fact we have both varchar and text feels like a wart.
Is that right? I don't feel varchar/text case is a wart. I
Hi,
Currently LWLOCK_PADDED_SIZE is defined as:
/*
* All the LWLock structs are allocated as an array in shared memory.
* (LWLockIds are indexes into the array.) We force the array stride to
* be a power of 2, which saves a few cycles in indexing, but more
* importantly also ensures that
On 23 Září 2013, 18:18, Pavel Stehule wrote:
Hello
2013/9/22 Tomas Vondra t...@fuzzy.cz
Hi,
I've reviewed the v6 of the numeric optimize patch
(http://www.postgresql.org/**message-id/**CAFj8pRDQhG7Pqmf8XqXY0PnHfakkP**
* Robert Haas (robertmh...@gmail.com) wrote:
I don't know why there shouldn't be a question about that.
Because anything else would be an internal optimization which must be
proven to be correct, imv, also..
Suppose
that the MAX() aggregate is in use. If 4 or 5 or 6 is updated so as
to
* Kevin Grittner (kgri...@ymail.com) wrote:
The only thing the paper says on the topic is that any incremental
maintenance scheme is a heuristic. There will always be cases when
it would be faster and less resource-intensive to regenerate the
data from the defining query. There is at least
On Sun, Sep 22, 2013 at 08:46:55PM +0200, Fabien wrote:
pgbench: reduce and compensate throttling underestimation bias.
This is a consequence of relying on an integer random generator,
which allow to ensure that delays inserted stay reasonably in
range of the target average delay.
The bias
On 9/23/13 12:54 PM, Andres Freund wrote:
I still find it wierd/inconsistent to have:
* pg_receivexlog
* pg_recvlogical
binaries, even from the same source directory. Why once pg_recv and
once pg_receive?
It's consistent because they are the same length!
(Obviously, this would severely
Here's an updated version; this mainly simplifies code, per comments
from Andres (things were a bit too baroque in places due to the way the
code had evolved, and I hadn't gone over it to simplify it).
The only behavior change is that the renegotiation is requested 1kB
before the limit is hit:
On 9/23/13 2:53 AM, MauMau wrote:
Yes, I believe you are right. Regardless of whether we support multiple
encodings in one database or not, a single client encoding will be
sufficient for one session. When receiving the Q message, the whole
SQL text is converted from the client encoding to
* Robert Haas (robertmh...@gmail.com) wrote:
In this case even something
like AVG() could produce the same result as it did before the update.
And you'd surely want to avoid updating the matview if the new value
was the same as what was already stored in the matview (but not if it
was equal
On Mon, Sep 23, 2013 at 12:47 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
It's probably an option to select 64 entries instead of 32.
There is still some regression in update speed. However, there is also
room for improvement patch. It searches item index entries 2 times on
insert: in
I am sure I am doing something wrong here, or this is an unsupported
feature, but I wanted to double check. I was hoping that if I did a
json_agg(x) and then copied that output of that and passed it into a
json_populate_recordset that I would get the record back. I know I can
make things work
From: Robert Haas robertmh...@gmail.com
Sure, it's EnterpriseDB's policy to add features that facilitate
migrations from other databases - particularly Oracle - to our
product, Advanced Server, even if those features don't otherwise add
any value. However, the community is usually reluctant to
On Mon, Sep 23, 2013 at 12:49 PM, Robert Haas robertmh...@gmail.com wrote:
Right, but what about XactLockTableWait() itself? It only acquires a
ShareLock on the xid of the got-there-first inserter that potentially
hasn't yet committed/aborted.
That's an interesting point. As you pointed out
On Mon, Sep 23, 2013 at 12:49 PM, Robert Haas robertmh...@gmail.com wrote:
and you cannot throw a serialization failure at read committed.
Not sure that's true, but at least it might not be the most desirable
behavior.
I'm pretty sure that that's totally true. You don't have to worry
about
* Kevin Grittner (kgri...@ymail.com) wrote:
I'm trying to figure out what situation you think we're in.
Seriously, if you could apply the patch and show one example that
demonstrates what you see to be a problem, that would be great.
Here's an example to illustrate what I'm talking about when
On Mon, Sep 23, 2013 at 9:21 PM, Stephen Frost sfr...@snowman.net wrote:
Here's an example to illustrate what I'm talking about when it comes
down to you can't claim that you'll produce exactly what the query
will always, with these types:
Your example demonstrates that if a given query can
On Mon, Sep 23, 2013 at 1:11 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andres Freund escribió:
On 2013-09-23 13:47:05 -0300, Alvaro Herrera wrote:
I had proposed pg_recvlogical
I still find it wierd/inconsistent to have:
* pg_receivexlog
* pg_recvlogical
binaries, even from the
On Tue, Sep 24, 2013 at 12:32 AM, Noah Misch n...@leadboat.com wrote:
On Mon, Sep 23, 2013 at 10:43:33AM +0530, Amit Kapila wrote:
On Mon, Sep 23, 2013 at 12:34 AM, Noah Misch n...@leadboat.com wrote:
On Sun, Sep 22, 2013 at 01:17:52PM +0530, Amit Kapila wrote:
#ifdef WIN32
/* use CRLF
On Mon, Sep 23, 2013 at 8:12 PM, Robert Haas robertmh...@gmail.com wrote:
The existence of a tool like
pg_receivellog seems to presuppose that the goal is spit out logical
change records as text, but I'm not sure that's actually going to be a
very common thing to want to do...
Sure, but I
On Fri, 2013-09-13 at 22:40 +0200, Dimitri Fontaine wrote:
Please find attached to this email three patches covering the missing PL
support for Event Triggers: pltcl, plperl and plpython.
You introduced some new compiler warnings, please fix those.
On Mon, Sep 23, 2013 at 7:06 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I think the idea that we should consider a different way of handling
tabular configuration data has merit. In fact, how much sense does it
make to have these options (the ones for which this patch is being
On 23 September 2013 at 23:37 Adam Jelinek ajeli...@gmail.com wrote:
I am sure I am doing something wrong here, or this is an unsupported feature,
but I wanted to double check. I was hoping that if I did a json_agg(x) and
then copied that output of that and passed it into a
82 matches
Mail list logo
