On Sunday 22 September 2013 01:34:53 Peter Eisentraut wrote:
On Thu, 2013-07-25 at 17:07 +0200, Ronan Dunklau wrote:
I am using approximatively the layout that was proposed here:
http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net
It looks like everything is hard-coded to
On 2013-09-23 23:12:53 -0400, Robert Haas wrote:
What exactly is the purpose of this tool? My impression is that the
output of logical replication is a series of function calls to a
logical replication plugin, but does that plugin necessarily have to
produce an output format that gets
On 2013-09-23 21:21:53 -0400, Stephen Frost 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:
=# table citext_table;
id | name
+---
1 | one
3 | three
On Tue, Sep 24, 2013 at 5:16 AM, Robert Haas robertmh...@gmail.com wrote:
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
Hi,
Various messages are discussing semantics around visibility. I by now
have a hard time keeping track. So let's keep the discussion of the
desired semantics to this thread.
There have been some remarks about serialization failures in read
committed transactions. I agree, those shouldn't
On 09/23/2013 10:38 PM, Stephen Frost wrote:
and heavily caveated.
I'm not sure what caveats would be needed. It seems to me that a
clear description of what it does would suffice. Like all the
other non-default opclasses in core, it will be non-default because
it is less frequently
--On 13. September 2013 20:17:19 -0400 Robert Haas robertmh...@gmail.com
wrote:
You're missing the point. Peter wasn't worried that your patch throws
an error; he's concerned about the fact that it doesn't.
In PostgreSQL, you can only create the following view because test1
has a primary
Andres Freund and...@2ndquadrant.com writes:
So, what we do is we guarantee that LWLocks are aligned to 16 or 32byte
boundaries. That means that on x86-64 (64byte cachelines, 24bytes
unpadded lwlock) two lwlocks share a cacheline.
Yup.
In my benchmarks changing the padding to 64byte
On 2013-09-24 12:39:39 +0200, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
So, what we do is we guarantee that LWLocks are aligned to 16 or 32byte
boundaries. That means that on x86-64 (64byte cachelines, 24bytes
unpadded lwlock) two lwlocks share a cacheline.
In my
* Robert Haas (robertmh...@gmail.com) wrote:
Your example demonstrates that if a given query can generate two
different outputs, A and B, based on the same input data, then the
contents of the materialized view cannot be equal to be A and also
equal to B. Well, no duh.
Two different outputs
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
From: Peter Eisentraut pete...@gmx.net
That assumes that the conversion client encoding - server encoding -
NCHAR encoding is not lossy.
Yes, so Tatsuo san suggested to restrict server encoding - NCHAR encoding
combination to those with lossless conversion.
I thought one main point of
Hello,
On Mon, 23 Sep 2013, Stephen Frost wrote:
I've now committed a fix for this issue.
I cloned the 9.4devel branch and linked my authmilter and a test program
(based on Heikki's earlier design) against the libpq that comes with it.
After hours of pretty extensive stress testing using 2,
Stephen Frost sfr...@snowman.net wrote:
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,
* Vesa-Matti J Kari (vmk...@cc.helsinki.fi) wrote:
Many thanks to all who contributed to the fix.
Great! Thanks for the report and the testing.
Stephen
signature.asc
Description: Digital signature
On 09/24/2013 12:59 AM, Chris Travers wrote:
I am still in the process of wrapping my head around the current JSON
logic. I hope to produce a proof of concept that can later be turned
into a patch. See my previous post on this topic. Again
collaboration is welcome.
Feel free to ask
On 09/23/2013 12:15 PM, Cédric Villemain wrote:
I'm working on it. It appears to have a slight problem or two I want
to fix at the same time, rather than backpatch something broken.
Would you mind sharing the problems you are facing ?
You've noticed the problem about installdirs, I suppose.
On Tue, Sep 24, 2013 at 7:14 AM, Stephen Frost sfr...@snowman.net wrote:
Of course, you don't need citext, or any other data type with a loose
notion of equality, to generate that sort of problem:
[...]
rhaas=# set datestyle = 'german';
SET
I'm talking about *planner differences* changing
Hello
There is new version of patch. I have separated ordering operators to different
patch (https://commitfest.postgresql.org/action/patch_view?id=1243), fixed
formatting issues and implemented backward compatibility with old-style points
in cube_is_point() and cube_out().
Also comparing
On 24 September 2013 at 13:46 Andrew Dunstan and...@dunslane.net wrote:
Feel free to ask questions.
The heart of the API is the event handlers defined in this stuct in
include/utils/jsonapi.h:
typedef struct JsonSemAction
{
void *semstate;
On Tue, Sep 24, 2013 at 6:48 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-24 12:39:39 +0200, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
So, what we do is we guarantee that LWLocks are aligned to 16 or 32byte
boundaries. That means that on x86-64 (64byte
On Tue, Sep 24, 2013 at 5:04 AM, David Rowley dgrowle...@gmail.com wrote:
So... I guess the question that I'd ask is, if you write a PL/pgsql
function that does RAISE NOTICE in a loop a large number of times, can
you measure any difference in how fast that function executes on the
patch and
On Mon, Sep 23, 2013 at 5:48 AM, Amit Khandekar
amit.khande...@enterprisedb.com 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
* Kevin Grittner (kgri...@ymail.com) wrote:
That's the point, and the whole point. You have not shown that it
doesn't. You have not shown why adding a 12th non-default opclass
is a particular problem here (although we have a consensus to use
different operators, to reserve this operator
On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
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
Stephen Frost sfr...@snowman.net wrote:
We need justification to add operators, imv, especially ones that
expose our internal binary representation of data.
I believe I have done so.
I worry that adding these will come back to bite us later
How?
and that we're making promises we won't be
On Mon, Sep 23, 2013 at 4:15 PM, Tomas Vondra t...@fuzzy.cz wrote:
Seems ready for commiter to me. I'll wait a few days for others to
comment, and then I'll update the commitfest page.
Some thoughts:
The documentation doesn't reflect the restriction to type internal.
On a related note, why
On Mon, Sep 23, 2013 at 7:05 PM, Peter Geoghegan p...@heroku.com wrote:
It suits my purposes to have the value locks be held for only an
instant, because:
[ detailed explanation ]
I don't really disagree with any of that. TBH, I think the question
of how long value locks (as you call them)
* Kevin Grittner (kgri...@ymail.com) wrote:
Stephen Frost sfr...@snowman.net wrote:
I worry that adding these will come back to bite us later
How?
User misuse is certainly one consideration, but I wonder what's going to
happen if we change our internal representation of data (eg: numerics
On Tue, Sep 24, 2013 at 5:58 AM, Bernd Helmle maili...@oopsware.de wrote:
--On 13. September 2013 20:17:19 -0400 Robert Haas robertmh...@gmail.com
wrote:
You're missing the point. Peter wasn't worried that your patch throws
an error; he's concerned about the fact that it doesn't.
In
On Tue, Sep 24, 2013 at 5:14 AM, Andres Freund and...@2ndquadrant.com wrote:
Various messages are discussing semantics around visibility. I by now
have a hard time keeping track. So let's keep the discussion of the
desired semantics to this thread.
There have been some remarks about
On Tue, Sep 24, 2013 at 4:15 AM, Andres Freund and...@2ndquadrant.com wrote:
There needs to be a client acking the reception of the data in some
form. There's currently two output methods, SQL and walstreamer, but
there easily could be further, it's basically two functions you have
write.
On Sun, Sep 22, 2013 at 3:40 PM, didier did...@gmail.com wrote:
fix a small memory leak in guc-file.l ParseConfigFile
AbsoluteConfigLocation() return a strdup string but it's never free or
referenced outside ParseConfigFile
Courtesy Valgrind and Noah Misch MEMPOOL work.
I'd like to look at
Abhijit Menon-Sen wrote:
I read through the patch, and it looks sensible.
Thanks for the thorough review!
I would have preferred the ldap_simple_bind_s() call in the HAVE_LIBLDAP
branch to not be inside an else {} (the if block above returns if there
is an error anyway), but that's a minor
Stephen Frost sfr...@snowman.net wrote:
Kevin Grittner (kgri...@ymail.com) wrote:
Stephen Frost sfr...@snowman.net wrote:
I worry that adding these will come back to bite us later
How?
User misuse is certainly one consideration,
I think that one has been talked to death already, with the
On 2013-09-24 11:04:06 -0400, Robert Haas wrote:
- Requiring a client is a short-sighted design. There's no reason we
shouldn't *support* having a client, but IMHO it shouldn't be the only
way to use the feature.
There really aren't many limitations preventing you from doing anything
else.
Hello, hackers.
In this patch I've implemented support for different storage types for cubes.
Now it supports float8, float4, int4, int2, int1. Type stored in the header of
each cube, one for all coordinates. So for cubes with int1 coordinates it can
save up to 8x disk space. Typed cubes can
* Kevin Grittner (kgri...@ymail.com) wrote:
Stephen Frost sfr...@snowman.net wrote:
The promise that we'll always return the binary representation of the
data that we saw last. When greatest(x,y) comes back 'false' for a
MAX(), we then have to go check well, does the type consider them
On 09/24/2013 11:21 AM, Andres Freund wrote:
Not having a consumer of the walsender interface included sounds like a
bad idea to me, even if it were only useful for testing. Now, you could
argue it should be in /contrib - and I wouldn't argue against that
except it shares code with the rest of
On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund and...@2ndquadrant.com wrote:
Hm, I guess you dont't want to add it to global/ or so because of the
mmap implementation where you presumably scan the directory?
Yes, and also because I thought this way would make it easier to teach
things like
Robert Haas escribió:
On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
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
Peter Eisentraut wrote:
In the source code, I'm dubious about the use of is_dml_trigger. I can
see where you are coming from, but in most of the code, a trigger is a
trigger and an event trigger is an event trigger. Let's not introduce
more terminology.
Other opinions on that?
I'm with
On Tue, Sep 24, 2013 at 12:00 PM, Stephen Frost sfr...@snowman.net wrote:
It wouldn't address my concerns anyway, which are around these binary
operators and the update-in-place approach being risky and setting us up
for problems down the road.
I think that if you want to hold up a bug fix to
On Tue, Sep 24, 2013 at 12:30 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I mean, if that 1kB limit is the only quarrel you have with this patch,
I'm happy.
You should probably be happy, then. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
David Rowley escribió:
I do see a 15-18% slow down with the patched version, so perhaps I'll need
to look to see if I can speed it up a bit, although I do feel this
benchmark is not quite a normal workload.
Ouch. That's certainly way too much. Is the compiler inlining
On Sat, Sep 14, 2013 at 11:14 AM, Abhijit Menon-Sen a...@2ndquadrant.comwrote:
Hi.
This is a cleaned-up and rebased version of the bitmap index patch from
Gavin Sherry, later revised by Gianni Ciolli and Gabriele Bartolini, and
others including Daniel Bausch.
I've been working on this
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Sep 24, 2013 at 12:00 PM, Stephen Frost sfr...@snowman.net wrote:
It wouldn't address my concerns anyway, which are around these binary
operators and the update-in-place approach being risky and setting us up
for problems down the road.
All,
I've send kernel.org a message that we're keen on seeing these changes
become committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh
All,
I've send kernel.org a message that we're keen on seeing these changes
get committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh
On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
David Rowley escribió:
I do see a 15-18% slow down with the patched version, so perhaps I'll need
to look to see if I can speed it up a bit, although I do feel this
benchmark is not quite a normal workload.
Ouch. That's certainly way
On Tue, Sep 24, 2013 at 1:04 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Sep 24, 2013 at 12:00 PM, Stephen Frost sfr...@snowman.net wrote:
It wouldn't address my concerns anyway, which are around these binary
operators and the
On 2013-09-24 12:19:51 -0400, Robert Haas wrote:
On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund and...@2ndquadrant.com wrote:
Hm, I guess you dont't want to add it to global/ or so because of the
mmap implementation where you presumably scan the directory?
Yes, and also because I
On 2013-09-24 19:56:32 +0200, Andres Freund wrote:
On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
David Rowley escribió:
I do see a 15-18% slow down with the patched version, so perhaps I'll need
to look to see if I can speed it up a bit, although I do feel this
benchmark is
Hello Noah,
meet all those goals simultaneously with simpler code, can we not?
int64 wait = (int64) (throttle_delay *
Min(7.0, -log(1 - pg_erand48(thread-random_state;
If you truncate roughly the multipler, as it is done here with min, you
* Robert Haas (robertmh...@gmail.com) wrote:
Now I admit that's an arguable point. We could certainly define an
intermediate notion of equality that is more equal than whatever =
does, but not as equal as exact binary equality.
I suggested it up-thread and don't recall seeing a response, so
Dear Robert,
(1) ...
I really don't think it's a good idea to change the default behavior.
We've had many discussions about how the overhead of gettimeofday() can
sometimes be surprisingly large; I don't think we should assume it's
guaranteed to be small in this case.
Also, changing
On Wed, Sep 25, 2013 at 6:25 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-09-24 19:56:32 +0200, Andres Freund wrote:
On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
David Rowley escribió:
I do see a 15-18% slow down with the patched version, so perhaps
I'll need
to
I agree with the best effort type of conversion, and only being able to
handle JSON array's that conform to an SQL array. With that said I would
love to collaborate with you on this, but there is one thing holding me
back. The current company I work for (an insurance company) says it is a
On Tue, Sep 24, 2013 at 3:14 PM, Adam Jelinek ajeli...@gmail.com wrote:
I agree with the best effort type of conversion, and only being able to
handle JSON array's that conform to an SQL array. With that said I would
love to collaborate with you on this, but there is one thing holding me
On 09/22/2013 10:44 PM, Fabien COELHO wrote:
Due to the possibly repetitive table structure of the data, maybe CSV
would make sense as well. It is less extensible, but it is directly
usable by sqlite or pg.
I'd be OK with CSV. At least I wouldn't be regexing the output.
--
Josh Berkus
Split 3 of the initial submission, which actually deal with data measured and
reported on stderr under various options.
This version currently takes into account many comments by Noah Mish. In
particular, the default no report behavior under benchmarking is not
changed, although I really
On Thu, Sep 12, 2013 at 09:38:43AM +0530, Amit Kapila wrote:
I have created the attached patch which issues an error when SET
TRANSACTION and SET LOCAL are used outside of transactions:
test= set transaction isolation level serializable;
ERROR: SET TRANSACTION can only
On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I have developed the attached patch based on your suggestion. I did not
see anything in the code that would make it STABLE, except a lookup of a
Jaime Casanova wrote:
Found another problem with the this steps:
create table t1 (i int);
create index idx_t1_i on t1 using minmax(i);
insert into t1 select generate_series(1, 200);
ERROR: could not read block 1 in file base/12645/16397_vm: read
only 0 of 8192 bytes
Thanks. This
Stephen Frost sfr...@snowman.net wrote:
I think the conservative (and therefore correct) approach is to
decide that we're always going to update if we detect any
difference at all.
And there may be users who are surprised that a refresh changed
parts of the table that have nothing to do
On Sep 24, 2013 10:12 AM, Josh Berkus j...@agliodbs.com wrote:
All,
I've send kernel.org a message that we're keen on seeing these changes
become committed.
I thought it was merged already in 3.12. There are a few related
patches, but here's one:
commit
At 2013-09-24 09:51:00 -0700, jeff.ja...@gmail.com wrote:
I get wrong answers from this index sometimes.
Thanks for the report and the test case. I'll investigate.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Sep 24, 2013 at 2:22 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Now I admit that's an arguable point. We could certainly define an
intermediate notion of equality that is more equal than whatever =
does, but not as equal as exact binary
On Tue, Sep 24, 2013 at 7:35 AM, Robert Haas robertmh...@gmail.com wrote:
I don't really disagree with any of that. TBH, I think the question
of how long value locks (as you call them) are held is going to boil
down to a question of how they end up being implemented.
Well, I think we can rule
On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
Hmm not sure i understand this argument either: this patch doesn't
allow disabling a primary key. It only supports FKs and CHECK
constraints explicitly.
Well, as soon as the patch for cataloging not-null constraints as check
constraints
On Tue, 2013-09-24 at 21:04 +0900, MauMau wrote:
4. I guess some users really want to continue to use ShiftJIS or EUC_JP for
database encoding, and use NCHAR for a limited set of columns to store
international text in Unicode:
- to avoid code conversion between the server and the client for
On Tue, Sep 24, 2013 at 9:49 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund and...@2ndquadrant.com wrote:
Hm, I guess you dont't want to add it to global/ or so because of the
mmap implementation where you presumably scan the directory?
Yes, and
72 matches
Mail list logo
