On 18/10/14 07:13, Josh Berkus wrote:
CK,
Before we go any further on this, how is Vitesse currently licensed?
last time we talked it was still proprietary. If it's not being
open-sourced, we likely need to take discussion off this list.
+1
Guys, you need to 'fess up on the licensing!
Rega
Indeed! A big part of our implementation is based on the Neumann
paper. There are also a few other papers that impacted our
implemented:
A. Ailamaki, D. DeWitt, M. Hill, D. Wood. DBMSs On A Modern Processor:
Where Does Time Go?
Peter Boncz, Marcin Zukowski, Niels Nes. MonetDB/X100:
Hyper-Pipelini
On Oct 17, 2014, at 3:18 PM, Tom Lane wrote:
> Yeah, exactly. Personally I'm *not* for this, but if we do it we should
> do it consistently: every comma-separated list in the SQL syntax should
> work the same.
PL/pgSQL, too, I presume.
D
smime.p7s
Description: S/MIME cryptographic signature
Hello,
As I said in the previous mail, I looked into the latest PCI DSS 3.0 to find
out whether and how pgaudit fulfills the requirements related to auditing.
I believe that even the initial version of pgaudit needs to have enough
functionalities to meet the requirements of some well-known sta
On Fri, 17 Oct 2014 13:12:27 -0400
Tom Lane wrote:
> CK Tan writes:
> > The bigint sum,avg,count case in the example you tried has some
> > optimization. We use int128 to accumulate the bigint instead of numeric in
> > pg. Hence the big speed up. Try the same query on int4 for the improvement
I wrote:
> Because it needs up-to-date min/max values in order to avoid being
> seriously misled about selectivities of values near the endpoints.
> See commit 40608e7f949fb7e4025c0ddd5be01939adc79eec.
BTW, on re-reading that code I notice that it will happily seize upon
the first suitable index (
Bruce Momjian writes:
> On Fri, Oct 17, 2014 at 06:15:37PM -0400, Tom Lane wrote:
>> Those stats were perfectly valid: what the planner is looking for is
>> accurate minimum and maximum values for the index's leading column, and
>> that's what it got. You're correct that a narrower index could ha
On Fri, Oct 17, 2014 at 06:15:37PM -0400, Tom Lane wrote:
> Marko Tiikkaja writes:
> > On 10/17/14, 11:59 PM, Tom Lane wrote:
> >> Well, the index might've been getting used in queries too in a way that
> >> really only involved the first column. I think you're solving the wrong
> >> problem here
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Oct 16, 2014 at 12:01:28PM -0400, Stephen Frost wrote:
> > This started out as a request for a non-superuser to be able to review
> > the log files without needing access to the server. Now, things can
> > certainly be set up on the server to imp
On Fri, Oct 17, 2014 at 6:25 PM, Feng Tian wrote:
> I feel sorting string as if it is bytea is particularly interesting. I am
> aware Peter G's patch and I think it is great, but for this sort agg case,
> first, I believe it is still slower than sorting bytea, and second, Peter
> G's patch depend
On Thu, Oct 16, 2014 at 12:01:28PM -0400, Stephen Frost wrote:
> This started out as a request for a non-superuser to be able to review
> the log files without needing access to the server. Now, things can
> certainly be set up on the server to import *all* logs and then grant
> access to a non-su
Hi, David,
Yes, switch sorting order would loose an interesting order so if user
dictates order by t, i; planner need to resort to its cost model.
Estimating cardinality of groupby is a much bigger topic than this thread.
I feel sorting string as if it is bytea is particularly interesting. I am
David Rowley writes:
> On Fri, Oct 17, 2014 at 3:34 AM, Tom Lane wrote:
>> I don't want to go there. It would be a lot better to expend the effort
>> on a better regression testing infrastructure that wouldn't *need*
>> bitwise-identical output across platforms. (mysql is ahead of us in that
>>
On Fri, Oct 17, 2014 at 3:34 AM, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-10-16 10:06:59 -0400, Tom Lane wrote:
> >> No, it wasn't. I'm not convinced either that that patch will get in at
> >> all, or that it has to have regression tests of that particular form,
> >> or that such a s
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/16/14 9:45 AM, Stephen Frost wrote:
> > Alright, coming back to this, I have to ask- how are matviews different
> > from views from the SQL standard's perspective? I tried looking through
> > the standard to figure it out (and I admit that I prob
* Nicolas Barbier (nicolas.barb...@gmail.com) wrote:
> 2014-10-16 Stephen Frost :
>
> > Alright, coming back to this, I have to ask- how are matviews different
> > from views from the SQL standard's perspective?
>
> Matviews that are always up to date when you access them are
> semantically exact
On Sat, Oct 18, 2014 at 12:35 PM, Tatsuo Ishii wrote:
> > The query,
> > select count(distinct j) from t group by t, i;
> >
> > runs for 35 seconds. However, if I change the query to,
> > select count(distinct j) from t group by i, t; -- note switching the
> > ordering
> > select count(distinct
On Sat, Oct 18, 2014 at 5:10 AM, Feng Tian wrote:
> Hi,
>
> Consider the following queries.
>
> create table t(i int, j int, k int, t text);
> insert into t select i, i % 100, i % 1000, 'AABBCCDD' || i from
> generate_series(1, 100) i;
>
> ftian=# explain select count(distinct j) from t group
> The query,
> select count(distinct j) from t group by t, i;
>
> runs for 35 seconds. However, if I change the query to,
> select count(distinct j) from t group by i, t; -- note switching the
> ordering
> select count(distinct j) from t group by decode(t, 'escape'), i; -- convert
> t to bytea
>
On 10/18/14, 12:15 AM, Tom Lane wrote:
Marko Tiikkaja writes:
I think there's a big difference between "this index was used to look up
stuff for planning" and "this index was used to answer queries quickly".
I think that's utter nonsense.
Well you probably know a bit more about the optimize
> It has been registered now
> (https://commitfest.postgresql.org/action/patch_view?id=1585). I've got
> an updated version of the patch with the documentation fix.
>
Looks like the patch is all good. I'm marking as ready for commiter.
On a side note, i'm noticing from http://en.wikipedia.org/wik
On 10/16/14, 11:46 PM, David G Johnston wrote:
Tom Lane-2 wrote
Something else mentioned was that once you start a smart shutdown you
have no good way (other than limited ps output) to see what the shutdown
is waiting on. I'd like to have some way to get back into the database
to see what's goin
Jim Nasby writes:
> As I originally posted, if we're going to do this I think we should do it
> *EVERYWHERE* commas are used as delimiters, save COPY input and output. Or we
> should at least get close to doing it everywhere. I think the only way things
> could get more annoying is if we accept
Marko Tiikkaja writes:
> On 10/17/14, 11:59 PM, Tom Lane wrote:
>> Well, the index might've been getting used in queries too in a way that
>> really only involved the first column. I think you're solving the wrong
>> problem here. The right problem is how to identify indexes that are
>> being us
On 10/16/14, 11:48 PM, David Johnston wrote:
We might as well allow a final trailing (or initial leading) comma on a
values list at the same time:
do you know, so this feature is a proprietary and it is not based on
ANSI/SQL? Any user, that use this feature and will to po
On 10/17/14, 11:59 PM, Tom Lane wrote:
Marko Tiikkaja writes:
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
So what I'd like to have is a way to be able to distinguish between
indexes being used to answer queries, and ones being only used for stats
lookups during planning.
Caleb Welton writes:
> A little while back some users started complaining that the contrib module
> I develop (MADlib) was failing to build with the following error:
> /usr/include/postgresql/9.2/server/port.h:480:32: error: declaration of
> 'char* mkdtemp(char*)' has a different exception specifi
On 10/17/14, 4:49 PM, Marko Tiikkaja wrote:
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the i
Marko Tiikkaja writes:
> On 10/17/14, 11:47 PM, Tom Lane wrote:
>> Marko Tiikkaja writes:
>>> So what I'd like to have is a way to be able to distinguish between
>>> indexes being used to answer queries, and ones being only used for stats
>>> lookups during planning.
>> Why? Used is used.
> Be
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the index was being used *all the
time*. However,
Marko Tiikkaja writes:
> This week we had one of the most annoying problems I've ever encountered
> with postgres. We had a big index on multiple columns, say, foo(a, b,
> c). According to pg_stat_all_indexes the index was being used *all the
> time*. However, after looking into our queries
Hi,
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the index was being used *all the
time*. However, after looking into our queries more closely, it turns
o
Alvaro Herrera writes:
> Merlin Moncure wrote:
>> On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan wrote:
>>> Following up something Pavel wrote, I notice that json_agg() and
>>> json_object_agg() are both marked as immutable, even though they invoke IO
>>> functions, while json_object is marked s
On 10/17/14, 4:31 AM, David G Johnston wrote:
Since the standard doesn't distinguish between read and write aspects of the
object types there isn't a safe way to add matviews to the information
schema that doesn't violate the intent of the provided view. If the
application/users wants to support
Merlin Moncure wrote:
> On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan wrote:
> > Following up something Pavel wrote, I notice that json_agg() and
> > json_object_agg() are both marked as immutable, even though they invoke IO
> > functions, while json_object is marked stable, even though it does
On Fri, Oct 17, 2014 at 1:44 PM, Merlin Moncure wrote:
> Is it too late to change them? Either way, it seems fairly
> implausible someone would come up with a case to stick json_agg(), or
> any aggregate function really, inside of an index. So it's not exactly
> the crime of the century.
Indexes
Hi,
Consider the following queries.
create table t(i int, j int, k int, t text);
insert into t select i, i % 100, i % 1000, 'AABBCCDD' || i from
generate_series(1, 100) i;
ftian=# explain select count(distinct j) from t group by t, i;
QUERY PLAN
---
A little while back some users started complaining that the contrib module
I develop (MADlib) was failing to build with the following error:
--
/usr/include/postgresql/9.2/server/port.h:480:32: error: declaration of
'char* mkdtemp(char*)' has a different exception specifier
/usr/include/stdlib
On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan wrote:
> Following up something Pavel wrote, I notice that json_agg() and
> json_object_agg() are both marked as immutable, even though they invoke IO
> functions, while json_object is marked stable, even though it does not, and
> can probably be mar
On 10/16/14 9:45 AM, Stephen Frost wrote:
> Alright, coming back to this, I have to ask- how are matviews different
> from views from the SQL standard's perspective? I tried looking through
> the standard to figure it out (and I admit that I probably missed
> something), but the only thing appears
Following up something Pavel wrote, I notice that json_agg() and
json_object_agg() are both marked as immutable, even though they invoke
IO functions, while json_object is marked stable, even though it does
not, and can probably be marked as immutable. Mea maxima culpa.
I'm not sure what we sh
On Mon, Sep 15, 2014 at 4:37 AM, Marko Tiikkaja wrote:
>
> I've changed the patch back to ignore signatures when not using the
> decrypt_verify() functions in the attached.
Hi Marko,
This patch needs a rebase now that the armor header patch has been
committed.
Thanks,
Jeff
Kevin Grittner wrote:
> Unless someone else wants to pick it up, I'll manage this one.
> Since there was no previous warning, I'll allow a grace day for the
> cut-off on submissions for this CF; if it isn't registered in the
> web application 24 hours after this email, I will move it to the
> ne
On 09/14/2014 06:32 PM, Peter Eisentraut wrote:
On 9/12/14 3:13 PM, Andreas 'ads' Scherbaum wrote:
Of course a general rule how to link to WP would be nice ...
I think Wikipedia links should be avoided altogether. We can assume
that readers are technically proficient to look up general techni
On 2014-10-16 20:22:24 -0400, Robert Haas wrote:
> On Thu, Oct 16, 2014 at 6:53 PM, Andres Freund wrote:
> > When using shared_buffers = 96GB there's a performance benefit, but not
> > huge:
> > master (f630b0dd5ea2de52972d456f5978a012436115e): 153621.8
> > master + LW_SHARED + lockl
Happy to contribute to that decision :-)
On Fri, Oct 17, 2014 at 11:35 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
>>> Well, that's pretty much cheating: it's too hard to disentangle what's
>>> coming from JIT vs what's coming from using a differ
On Fri, Oct 17, 2014 at 12:56:52PM -0400, Tom Lane wrote:
> David G Johnston writes:
> > The question is whether we explain the implications of not being WAL-logged
> > in an error message or simply state the fact and let the documentation
> > explain the hazards - basically just output:
> > "hash
Andres Freund writes:
> On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
>> Well, that's pretty much cheating: it's too hard to disentangle what's
>> coming from JIT vs what's coming from using a different accumulator
>> datatype. If we wanted to depend on having int128 available we could
>> get tha
On Fri, Oct 17, 2014 at 1:21 PM, Peter Geoghegan wrote:
> On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian wrote:
>> I agree using that using int128 in stock postgres will speed up things too.
>> On the other hand, that is only one part of the equation. For example, if
>> you look at TPCH Q1, the in
On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
> Well, that's pretty much cheating: it's too hard to disentangle what's
> coming from JIT vs what's coming from using a different accumulator
> datatype. If we wanted to depend on having int128 available we could
> get that speedup with a couple hours
On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian wrote:
> I agree using that using int128 in stock postgres will speed up things too.
> On the other hand, that is only one part of the equation. For example, if
> you look at TPCH Q1, the int128 "cheating" does not kick in at all, but we
> are 8x faste
On 2014-10-17 17:14:16 +0530, Amit Kapila wrote:
> On Tue, Oct 14, 2014 at 11:34 AM, Amit Kapila
> wrote:
> >
> >
> > I am not sure why we are seeing difference even though running
> > on same m/c with same configuration.
>
> I have tried many times, but I could not get the numbers you have
> pos
CK,
Before we go any further on this, how is Vitesse currently licensed?
last time we talked it was still proprietary. If it's not being
open-sourced, we likely need to take discussion off this list.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailin
Hi, Tom,
Sorry for double post to you.
Feng
-- Forwarded message --
From: Feng Tian
Date: Fri, Oct 17, 2014 at 10:29 AM
Subject: Re: [HACKERS] Vitesse DB call for testing
To: Tom Lane
Hi, Tom,
I agree using that using int128 in stock postgres will speed up things
too. On th
CK Tan writes:
> The bigint sum,avg,count case in the example you tried has some optimization.
> We use int128 to accumulate the bigint instead of numeric in pg. Hence the
> big speed up. Try the same query on int4 for the improvement where both pg
> and vitessedb are using int4 in the executio
Alvaro Herrera writes:
> Dag-Erling Smørgrav wrote:
>> I understand this policy. However, this new feature a) has absolutely
>> no impact unless the admin makes a conscious decision to use it and b)
>> will make life much easier for everyone if a POODLE-like vulnerability
>> is discovered in TLS.
David G Johnston writes:
> The question is whether we explain the implications of not being WAL-logged
> in an error message or simply state the fact and let the documentation
> explain the hazards - basically just output:
> "hash indexes are not WAL-logged and their use is discouraged"
+1. The
Rushabh Lathia writes:
> pg_dump binary-upgrade fail with segmentation fault for type without
> element.
Ooops.
> Looking further into code I found that rather then fetching typrelid, we can
> use the already stored typrelid from TypeInfo structure.
Agreed. Patch committed, thanks!
Bruce Momjian wrote
> Now that we have the create hash index warning in 9.5, I realized that
> we don't warn about hash indexes with PITR, only crash recovery and
> streaming. This patch fixes that.
>
> Is the wording "cannot be used" too vague. The CREATE INDEX manual
> page has the words "give
Dag-Erling Smørgrav wrote:
> Michael Paquier writes:
> > Please note that new features can only be added to the version
> > currently in development, aka 9.5.
>
> I understand this policy. However, this new feature a) has absolutely
> no impact unless the admin makes a conscious decision to use
Now that we have the create hash index warning in 9.5, I realized that
we don't warn about hash indexes with PITR, only crash recovery and
streaming. This patch fixes that.
Is the wording "cannot be used" too vague. The CREATE INDEX manual
page has the words "give wrong answers to queries", whic
On Oct 17, 2014 6:16 PM, "Tom Lane" wrote:
> A more realistic objection goes like this:
>
> create table foo(f int, g int);
> update foo x set x = (1,2); -- works
> alter table foo add column x int;
> update foo x set x = (1,2,3); -- no longer works
>
> It's not a real good thing if a column add
On Fri, Oct 17, 2014 at 10:47 AM, CK Tan wrote:
> Merlin, glad you tried it.
>
> We take the query plan exactly as given by the planner, decide whether to JIT
> or to punt depending on the cost. If we punt, it goes back to pg executor. If
> we JIT, and if we could not proceed (usually of some op
On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
>>> I think it wouldn't; Merlin is proposing that f would be taken as the
>>> field name. A more realistic objection goes like this:
>>>
>>> create table foo(f int, g
Merlin, glad you tried it.
We take the query plan exactly as given by the planner, decide whether to JIT
or to punt depending on the cost. If we punt, it goes back to pg executor. If
we JIT, and if we could not proceed (usually of some operators we haven't
implemented yet), we again punt. Once
Merlin Moncure writes:
> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
>> I think it wouldn't; Merlin is proposing that f would be taken as the
>> field name. A more realistic objection goes like this:
>>
>> create table foo(f int, g int);
>> update foo x set x = (1,2); -- works
>> alter t
Pavel Stehule wrote:
> do you know, so this feature is a proprietary and it is not based
> on ANSI/SQL? Any user, that use this feature and will to port to
> other database will hate it.
I remember that Sybase ASE allowed a trailing comma within the
parentheses of a table definition, which was h
On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> local:marko=#* create table foo(f int);
>> CREATE TABLE
>> local:marko=#* update foo f set f=1;
>> UPDATE 0
>
>> This query would change meaning with your suggestion.
>
> I think it wouldn't; Merlin is proposing that f
Marko Tiikkaja writes:
> local:marko=#* create table foo(f int);
> CREATE TABLE
> local:marko=#* update foo f set f=1;
> UPDATE 0
> This query would change meaning with your suggestion.
I think it wouldn't; Merlin is proposing that f would be taken as the
field name. A more realistic objection
On Fri, Oct 17, 2014 at 10:10 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja wrote:
>>> I don't know about Tom, but I didn't like that:
>>> http://www.postgresql.org/message-id/5364c982.7060...@joh.to
>
>> Hm, I didn't understand your objection:
>
Merlin Moncure writes:
> On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
>> Thanks for the links, but this patch only targets SET(*) case, which, if I
>> understand correctly, the patch you mentioned doesn't directly handle (If I
>> understand correctly, the target of the two patches is diffe
Merlin Moncure writes:
> On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja wrote:
>> I don't know about Tom, but I didn't like that:
>> http://www.postgresql.org/message-id/5364c982.7060...@joh.to
> Hm, I didn't understand your objection:
>
> So e.g.:
>UPDATE foo f SET f = ..;
> would resol
On 17 October 2014 14:05, Alvaro Herrera wrote:
> Of course, this is a task that requires much more thinking, design, and
> discussion than just adding multi-process capability to vacuumdb ...
Yes, please proceed with this patch as originally envisaged. No more
comments from me.
--
Simon Rigg
On 10/17/14 5:03 PM, Merlin Moncure wrote:
Hm, I didn't understand your objection:
So e.g.:
UPDATE foo f SET f = ..;
would resolve to the table, despite there being a column called "f"?
That would break backwards compatibility.
That's not correct: it should work exactly as 'select' does;
On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja wrote:
> On 10/17/14 4:15 PM, Merlin Moncure wrote:
>>
>> Any particular reason why you couldn't have just done:
>>
>> UPDATE table1 SET * = a,b,c, ...
>
>
> That just looks wrong to me. I'd prefer (*) = .. over that any day.
>
>> UPDATE table1 t
On 10/17/14 4:15 PM, Merlin Moncure wrote:
Any particular reason why you couldn't have just done:
UPDATE table1 SET * = a,b,c, ...
That just looks wrong to me. I'd prefer (*) = .. over that any day.
UPDATE table1 t SET t = (SELECT (a,b,c)::t FROM...);
seems cleaner than the proposed synt
On Fri, Oct 17, 2014 at 7:45 PM, Merlin Moncure wrote:
> On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
> >
> >
> > On Wednesday, October 15, 2014, Marti Raudsepp wrote:
> >>
> >> Hi
> >>
> >> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma
> wrote:
> >> > Please find attached a patch which
On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
>
>
> On Wednesday, October 15, 2014, Marti Raudsepp wrote:
>>
>> Hi
>>
>> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma wrote:
>> > Please find attached a patch which implements support for UPDATE table1
>> > SET(*)=...
>>
>> I presume you hav
On Fri, Oct 17, 2014 at 8:14 AM, Merlin Moncure wrote:
> On Fri, Oct 17, 2014 at 7:32 AM, CK Tan wrote:
>> Hi everyone,
>>
>> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
>> designed for compute intensive OLAP workload. We have gotten it to a
>> reasonable state and would l
On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masao wrote:
> In this case, the patch seems to make the restartpoint recycle even WAL
> files
> which have .ready files and will have to be archived later. Thought?
>
The real problem currently is that it is possible to have a segment file
not marked as .do
On Fri, Oct 17, 2014 at 7:32 AM, CK Tan wrote:
> Hi everyone,
>
> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
> designed for compute intensive OLAP workload. We have gotten it to a
> reasonable state and would like to open it up to the pg hackers
> community for testing and
On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masao wrote:
> On Thu, Oct 9, 2014 at 3:26 PM, Michael Paquier
> wrote:
>>
>>
>> On Wed, Oct 8, 2014 at 10:00 PM, Michael Paquier
>> wrote:
>>>
>>> The additional process at promotion sounds like a good idea, I'll try to
>>> get a patch done tomorrow. This
Amit Kapila wrote:
> On Fri, Oct 17, 2014 at 1:31 AM, Simon Riggs wrote:
> >
> > On 16 October 2014 15:09, Amit Kapila wrote:
> > c) seems like the only issue that needs any thought. I don't think its
> > going to be that hard.
> >
> > I don't see any problems with the other points. You can make
On 17 October 2014 12:52, Amit Kapila wrote:
> It is quite possible, but still I think to accomplish such a function,
> we need to have some mechanism where it can inform auto vacuum
> and then some changes in auto vacuum to receive/read that information
> and reply back. I don't think any such
Hi,
On 2014-10-17 05:32:13 -0700, CK Tan wrote:
> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
> designed for compute intensive OLAP workload. We have gotten it to a
> reasonable state and would like to open it up to the pg hackers
> community for testing and suggestions.
>
Michael Paquier writes:
> Please note that new features can only be added to the version
> currently in development, aka 9.5.
I understand this policy. However, this new feature a) has absolutely
no impact unless the admin makes a conscious decision to use it and b)
will make life much easier fo
On 2014-10-17 14:57:03 +0800, Craig Ringer wrote:
> On 10/17/2014 02:49 AM, Robert Haas wrote:
> > I think you could probably make the DELETE policy control what can get
> > deleted, but then have the SELECT policy further filter what gets
> > returned.
>
> That seems like the worst of both worlds
Hi everyone,
Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
designed for compute intensive OLAP workload. We have gotten it to a
reasonable state and would like to open it up to the pg hackers
community for testing and suggestions.
Vitesse DB offers
-- JIT Compilation for com
On Fri, Oct 17, 2014 at 7:46 AM, Stephen Frost wrote:
> Thoughts on 'WITH RETURNING' / 'WITHOUT RETURNING' and what the default
> should be?
That sounds like a horrendous pile of nasty complication for no good purpose.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
On Thu, Oct 9, 2014 at 3:26 PM, Michael Paquier
wrote:
>
>
> On Wed, Oct 8, 2014 at 10:00 PM, Michael Paquier
> wrote:
>>
>> The additional process at promotion sounds like a good idea, I'll try to
>> get a patch done tomorrow. This would result as well in removing the
>> XLogArchiveForceDone stu
* David G Johnston (david.g.johns...@gmail.com) wrote:
> How about returning a placeholder row but with all the values replaced with
> NULL?
I don't think that would be a good approach.. A user actually looking
at those rows would be highly confused.
> In the absence of returning does the delete
On Fri, Oct 17, 2014 at 1:31 AM, Simon Riggs wrote:
>
> On 16 October 2014 15:09, Amit Kapila wrote:
>
> > I think doing anything on the server side can have higher complexity
like:
> > a. Does this function return immediately after sending request to
> > autovacuum, if yes then the behaviour of
* Thom Brown (t...@linux.com) wrote:
> On 17 October 2014 07:57, Craig Ringer wrote:
> > On 10/17/2014 02:49 AM, Robert Haas wrote:
> > > I think you could probably make the DELETE policy control what can get
> > > deleted, but then have the SELECT policy further filter what gets
> > > returned.
>
* Fujii Masao (masao.fu...@gmail.com) wrote:
> Another minor problem that I found is that pg_dump always fails when
> there is a row-level policy for update. I think that the attached patch
> should be applied.
Urgh. That was tested before but we switched the characters used and
evidently missed
On Tue, Oct 14, 2014 at 11:34 AM, Amit Kapila
wrote:
>
>
> I am not sure why we are seeing difference even though running
> on same m/c with same configuration.
I have tried many times, but I could not get the numbers you have
posted above with HEAD, however now trying with the latest version
[1]
On Fri, Oct 17, 2014 at 7:58 PM, Dag-Erling Smørgrav wrote:
> The default is "ALL:-SSLv2" in 9.0-9.3 and "ALL:-SSL" in 9.4 and up.
> This corresponds to the current hardcoded values, so the default
> behavior is unchanged, but the admin now has the option to select a
> different settings, e.g. if
On Fri, Oct 17, 2014 at 3:49 AM, Robert Haas wrote:
>>> That's an argument in favour of only applying a read-filtering policy
>>> where a RETURNING clause is present, but that introduces the "surprise!
>>> the effects of your DELETE changed based on an unrelated clause!" issue.
>>
>> No- if we wer
2014-10-17 9:14 GMT+02:00 Petr Jelinek :
> On 16/10/14 13:29, Pavel Stehule wrote:
>
>> Hi
>>
>> 2014-10-14 22:57 GMT+02:00 Petr Jelinek >
>> Short review of the patch. Note that this has nothing to do with
>> actual assertions, at the moment it's just enhancement of RAISE
>> statement
On 17 October 2014 09:55, wrote:
>>A new parameter to send feedback should be called --feedback
>>A second parameter to decide whether to fsync should be called --fsync
>
> I think keep using "--reply-fsync" and "--fsync-interval" is better than make
> new options.
> Thought?
We already have
The attached patches add an ssl_protocols configuration option which
control which versions of SSL or TLS the server will use. The syntax is
similar to Apache's SSLProtocols directive, except that the list is
colon-separated instead of whitespace-separated, although that is easy
to change if it pr
1 - 100 of 109 matches
Mail list logo
