On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón
wrote:
>> Both seem a step backwards IMO.
>
> Hmmm... as opposed to breaking applications innecesarily when simply
> enabling SSL/TLS would not make it insecure? or when users don't really need
> it?
No, as opposed to cases where people are alrea
On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
wrote:
> On 02/11/2015 06:35 AM, Claudio Freire wrote:
>>
>> Usually because handshakes use a random salt on both sides. Not sure
>> about pg's though, but in general collision strength is required but
>> not slow
On Wed, Feb 11, 2015 at 6:30 PM, Claudio Freire wrote:
> On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
> wrote:
>> On 02/11/2015 06:35 AM, Claudio Freire wrote:
>>>
>>> Usually because handshakes use a random salt on both sides. Not sure
>>> abou
On Thu, Feb 19, 2015 at 3:44 PM, Kevin Grittner wrote:
>> I'm also interested in handling the case Stephen Frost described, where
>> a tuple is effectively dead but we don't currently have the means of
>> discovering the fact, because there is an older long running transaction
>> which is never in
On Wed, Dec 3, 2014 at 2:09 PM, Robert Haas wrote:
> On Wed, Dec 3, 2014 at 12:08 PM, Tom Lane wrote:
>> I would envision the planner starting out generating the first subplan
>> (without the optimization), but as it goes along, noting whether there
>> are any opportunities for join removal. At
On Thu, Dec 4, 2014 at 4:11 PM, Matt Newell wrote:
> With the API i am proposing, only 2 new functions (PQgetFirstQuery,
> PQgetLastQuery) are required to be able to match each result to the query that
> caused it. Another function, PQgetNextQuery allows iterating through the
> pending queries, a
On Fri, Dec 12, 2014 at 6:48 PM, Robert Haas wrote:
> On Fri, Dec 12, 2014 at 4:28 PM, Jim Nasby wrote:
>>> Sure. Mind you, I'm not proposing that the syntax I just mooted is
>>> actually for the best. What I'm saying is that we need to talk about
>>> it.
>>
>> Frankly, if we're going to requir
On Fri, Dec 12, 2014 at 7:10 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Fri, Dec 12, 2014 at 6:48 PM, Robert Haas wrote:
>>> I have very little idea what the API you're imagining would actually
>>> look like from this description, but it sounds like a ter
On Fri, Dec 12, 2014 at 7:25 PM, Michael Paquier
wrote:
> On Sat, Dec 13, 2014 at 1:08 AM, Robert Haas wrote:
>> On Fri, Dec 12, 2014 at 10:04 AM, Andres Freund wrote:
Note that autovacuum and fsync are off.
=# select phase, user_diff, system_diff,
pg_size_pretty(pre_update - pre_
On Fri, Dec 12, 2014 at 7:40 PM, Josh Berkus wrote:
> On 12/12/2014 02:10 PM, Tom Lane wrote:
>> Actually, I'm not sure that's what we want. I thought what we really
>> wanted here was to postpone partition-routing decisions to runtime,
>> so that the behavior would be efficient whether or not th
El 12/12/2014 23:09, "Alvaro Herrera" escribió:
>
> Claudio Freire wrote:
>
> > Fair enough, but that's not the same as not requiring easy proofs. The
> > planner might not the one doing the proofs, but you still need proofs.
> >
> > Even if the p
On Sun, Dec 14, 2014 at 11:12 PM, Amit Langote
wrote:
>> On egress you need some direct way to compare the scan quals with the
>> partitioning values. I would imagine this to be similar to how scan
>> quals are compared to the values stored in a BRIN index: each scan qual
>> has a corresponding o
On Mon, Dec 15, 2014 at 8:09 AM, José Luis Tallón
wrote:
> On 12/15/2014 07:42 AM, Claudio Freire wrote:
>>
>> [snip]
>
>
>> If you do that, you start with empty partitions, and each insert updates
>> the BRIN tuple. Avoiding concurrency loss in this case would
On Tue, Dec 16, 2014 at 8:09 AM, Mark Cave-Ayland
wrote:
> For the spare time that I have for review, one of these projects
> requires me to download attachment(s), apply them to a git tree
> (hopefully it still applies), run a complete "make check" regression
> series, try and analyse a patch whi
On Tue, Dec 16, 2014 at 12:15 PM, Robert Haas wrote:
> wrote:
>> Robert wrote:
>>> On Sun, Dec 14, 2014 at 9:12 PM, Amit Langote
>>> wrote:
>>> > This means if a user puts arbitrary expressions in a partition
>>> > definition, say,
>>> >
>>> > ... FOR VALUES extract(month from current_date) TO
On Tue, Dec 16, 2014 at 11:47 AM, Mark Cave-Ayland
wrote:
> On 16/12/14 13:37, Claudio Freire wrote:
>
>>> For the second project, I can skim through my inbox daily picking up
>>> specific areas I work on/are interested in, hit reply to add a couple of
>>> line
On Fri, Jan 2, 2015 at 2:11 PM, Andres Freund wrote:
>> , I now see the compression patch as something that has negatives, so
>> has to be set by the user, and only wins in certain cases. I am
>> disappointed, and am trying to figure out how this became such a
>> marginal win for 9.5. :-(
>
> I
On Fri, Jan 2, 2015 at 7:57 PM, Jim Nasby wrote:
> On 1/2/15, 4:18 PM, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>>
>>> >On 01/02/2015 11:41 PM, Tom Lane wrote:
>>What might be worth trying is establishing a hard-and-fast boundary
>>between C land and SQL land, with bitwise
On Fri, Jun 5, 2015 at 2:59 PM, Tom Lane wrote:
> deavid writes:
>> Some people already asked for "delayed write" indexes, but the idea gets
>> discarded because the index could get out of sync, so it can omit results
>> and this is unacceptable. But i think maybe that could be fixed in several
>
On Mon, Jun 8, 2015 at 12:22 PM, Geoff Winkless wrote:
> On 8 June 2015 at 16:01, Robert Haas wrote:
>>
>> On Mon, Jun 8, 2015 at 9:21 AM, Geoff Winkless
>> wrote:
>> > Wow! I never knew there were all these people out there who would be
>> > rushing
>> > to help test if only the PG developers r
On Wed, Jun 10, 2015 at 6:01 PM, deavid wrote:
> By now, my results were a bit disappointing: (comparing gin_btree against
> regular btree for a column with very low cardinality)
> - create index and updates: about 10-20% faster (i had a primary key, so
> btree unique checks may be here blurring t
On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> On 07/07/2015 04:31 PM, Stephen Frost wrote:
>> >The alternative is to have monitoring tools which are running as
>> >superuser, which, in my view at least, is far worse.
>>
>> Or don't enable
On Tue, Jul 7, 2015 at 2:24 PM, Stephen Frost wrote:
> * Claudio Freire (klaussfre...@gmail.com) wrote:
>> On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote:
>> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> >> On 07/07/2015 04:31 PM, Stephen Frost wrote:
>
On Tue, Jul 7, 2015 at 2:29 PM, Stephen Frost wrote:
>> Or another crazy idea is to append "random length" dummy data into
>> compressed FPW. Which would make it really hard for an attacker to
>> guess the information from WAL location. Even if this option is enabled,
>> you can still have the per
On Wed, Aug 3, 2016 at 4:20 AM, Simon Riggs wrote:
> == IndexScan ==
>
> Note that the executor code for IndexScan appears identical between
> the two optimizations. The difference between duplicate and range LITE
> tuples is needed only at INSERT time (or UPDATE indexed column to a
> new value).
On Wed, Aug 3, 2016 at 4:37 PM, Claudio Freire wrote:
> On Wed, Aug 3, 2016 at 4:20 AM, Simon Riggs wrote:
>> == IndexScan ==
>>
>> Note that the executor code for IndexScan appears identical between
>> the two optimizations. The difference between duplicate and ran
On Thu, Aug 4, 2016 at 7:59 AM, Pavan Deolasee wrote:
> We don’t want to force a recheck for every index fetch because that will
> slow everything down. So we would like a simple and efficient way of knowing
> about the existence of a WARM tuple in a chain and do a recheck in only
> those cases, i
On Thu, Aug 4, 2016 at 1:58 PM, Simon Riggs wrote:
> On 3 August 2016 at 20:37, Claudio Freire wrote:
>> On Wed, Aug 3, 2016 at 4:20 AM, Simon Riggs wrote:
>>> == IndexScan ==
>>>
>>> Note that the executor code for IndexScan appears identical between
>&
On Thu, Aug 4, 2016 at 2:14 PM, Claudio Freire wrote:
> To fix this, what I was pondering, and I believe it would be viable,
> is to teach heap_hot_search_buffer about the WARM invariant. It will
> make correctness heavily depend on the invariant being true, which
> means either f
On Thu, Aug 4, 2016 at 3:07 PM, Bruce Momjian wrote:
> On Thu, Aug 4, 2016 at 02:35:32PM -0300, Claudio Freire wrote:
>> > Vacuum will need to be taught not to break the invariant, but I
>> > believe this is viable and efficient.
>>
>>
>> And I didn'
On Thu, Aug 4, 2016 at 3:23 PM, Claudio Freire wrote:
>> That is a new HOT chain given our current code, but
>> would the new tuple addition realize it needs to create a new index
>> tuple? The new tuple code needs to check the index's root HOT tid for a
>> non-ma
On Thu, Aug 4, 2016 at 7:21 PM, Bruce Momjian wrote:
> On Thu, Aug 4, 2016 at 03:23:10PM -0300, Claudio Freire wrote:
>> INSERT INTO TABLE t (id,val,dat) VALUES (32,'a','blabla');
>> UPDATE t SET dat='blabla2' where id = 32;
>> UPDATE t SET dat=
On Thu, Aug 4, 2016 at 7:59 AM, Pavan Deolasee wrote:
> So marking the index would require us to mark both old and new index tuples
> as requiring re-check. That requires an additional index scan to locate the
> old row and then an additional write to force it to re-check, which is
> algorithmical
On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote:
> On Thu, Aug 4, 2016 at 09:53:31PM -0300, Claudio Freire wrote:
>> It's the other way around. A WARM chain has to span whole HOT chains.
>> The WARM chain always begins in the head of a HOT chain (or non-HOT
>> tu
On Fri, Aug 5, 2016 at 12:44 AM, Bruce Momjian wrote:
>> UPDATE t SET dat = dat + 1, id = 3, someid = 3 where id = 2;
>
> This is ends the WARM chain, and creates new index entries because all
> indexes are changed.
>
>> UPDATE t SET dat = dat + 1, id = 1, someid = 2 where id = 3;
>
> This does th
On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee wrote:
>
>
> On Fri, Aug 5, 2016 at 8:23 AM, Claudio Freire
> wrote:
>>
>> On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote:
>>
>> >
>> > OK, that's a lot of text, and I am confused. Pleas
On Fri, Aug 5, 2016 at 2:26 PM, Pavan Deolasee wrote:
> On Fri, Aug 5, 2016 at 8:55 PM, Claudio Freire
> wrote:
>>
>> On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee
>> wrote:
>> >
>> >
>> > I don't see why it is hard. Trying to find th
On Fri, Aug 5, 2016 at 4:26 PM, Bruce Momjian wrote:
> On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote:
>> On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote:
>>
>> On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote:
>> > But doi
On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote:
> On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
>> > This does create more HOT chains where the root ctid cannot be removed,
>> > but it does avoid the index key/ctid check because any entry in the HOT
>
On Fri, Aug 5, 2016 at 9:21 PM, Claudio Freire wrote:
> On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote:
>> On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
>>> > This does create more HOT chains where the root ctid cannot be removed,
>>> > but
On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee wrote:
>>
>> My guess is we would need one bit to mark a WARM chain, and perhaps
>> reuse obsolete pre-9.0 HEAP_MOVED_OFF to indicate increment-only or
>> decrement-only.
>
>
> I am not convinced that the checking for increment/decrement adds a lot of
On Mon, Aug 8, 2016 at 5:24 PM, Bruce Momjian wrote:
> On Mon, Aug 8, 2016 at 03:36:12PM -0300, Claudio Freire wrote:
>> I think I prefer a more thorough approach.
>>
>> Increment/decrement may get very complicated with custom opclasses,
>> for instance. A column-chan
On Tue, Aug 9, 2016 at 8:19 PM, Jim Nasby wrote:
> On 8/8/16 3:19 PM, Bruce Momjian wrote:
>>>
>>> What will help, and something I haven't yet applied any thoughts, is when
>>> we
>>> > can turn WARM chains back to HOT by removing stale index entries.
>>
>> I can't see how we can ever do that beca
On Tue, Aug 9, 2016 at 8:44 PM, Claudio Freire wrote:
> index 0 1 2 3 4
> k1 .. a a a
> k2 .. b a a
> i1 ^
> i2 ^ ^
> lp u u r3
> hot*
Sorry, that should read:
index 0 1 2 3
On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby wrote:
> On 8/9/16 6:44 PM, Claudio Freire wrote:
>>
>> Since we can lookup all occurrences of k1=a index=0 and k2=a index=0,
>> and in fact we probably did so already as part of the update logic
>
>
> That's a change
On Mon, Aug 8, 2016 at 4:44 PM, Peter Geoghegan wrote:
> The basic idea I have in mind is that we create runs in workers in the
> same way that the parallel CREATE INDEX patch does (one output run per
> worker). However, rather than merging in the leader, we use a
> splitting algorithm to determin
On Wed, Aug 10, 2016 at 4:37 PM, Simon Riggs wrote:
> On 10 August 2016 at 03:45, Pavan Deolasee wrote:
>>
>>
>> On Tue, Aug 9, 2016 at 12:06 AM, Claudio Freire
>> wrote:
>>>
>>> On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee
>>> wrote:
On Thu, Aug 11, 2016 at 11:07 AM, Jim Nasby wrote:
> On 8/10/16 12:48 PM, Claudio Freire wrote:
>>
>> On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby
>> wrote:
>>>
>>> On 8/9/16 6:44 PM, Claudio Freire wrote:
>>>>
>>>>
>>&g
On Fri, Aug 12, 2016 at 1:55 PM, amul sul wrote:
> No segfault during dsm_create, mmap returns the memory address which is
> inaccessible.
>
> Let me see how can I disable kernel overcommit behaviour, but IMHO, we
> should prevent ourselves from crashing, shouldn't we?
Overcommit can be cau
On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby wrote:
> Even better would be if the planner could estimate how bad a plan will
> become if we made assumptions that turn out to be wrong.
>
That's precisely what risk estimation was about.
Something like
SELECT * FROM wherever WHEN id > something LIM
On Mon, Mar 17, 2014 at 7:09 PM, Jim Nasby wrote:
> On 3/17/14, 2:16 PM, Merlin Moncure wrote:
>
>> On Mon, Mar 17, 2014 at 1:45 PM, Pavel Stehule
>> wrote:
>>
>>> >I don't believe so SELECTIVITY can work well too. Slow queries are
>>> usually
>>> >related to some strange points in data. I am th
On Mon, Mar 17, 2014 at 7:12 PM, Jim Nasby wrote:
> On 3/17/14, 5:07 PM, Claudio Freire wrote:
>
>
>> On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby > j...@nasby.net>> wrote:
>>
>> Even better would be if the planner could estimate how bad a plan
>> wi
On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote:
> Claudio Freire writes:
> > On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby wrote:
> >> Even better would be if the planner could estimate how bad a plan will
> >> become if we made assumptions that turn out to be wrong.
On Tue, Mar 18, 2014 at 4:48 PM, Merlin Moncure wrote:
> > That alone could improve things considerably, and statistical info could
> be
> > propagated along expressions to make it possible to model uncertainty in
> > complex expressions as well.
>
> But how would that work? I see no solution ad
On Thu, Mar 20, 2014 at 5:55 PM, Alexandr wrote:
>> Subtracting to get an interval, then converting that interval to seconds
>> or minutes could give you a value that's wildly different from the right
>> answer.
>
> Can you explain me when it happens ?
'1 month'::interval
It's different dependi
On Mon, Mar 31, 2014 at 6:21 PM, Robert Haas wrote:
> On Fri, Mar 28, 2014 at 11:30 AM, Alexander Korotkov
> wrote:
>> after reading Heikki Linnakangas presentation about GIN from Nordic PGDay, I
>> figure out that btree_gin became much more attractive.
>> http://hlinnaka.iki.fi/presentations/Nor
On Mon, Mar 31, 2014 at 6:37 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Mon, Mar 31, 2014 at 6:21 PM, Robert Haas wrote:
>>> On Fri, Mar 28, 2014 at 11:30 AM, Alexander Korotkov
>>> wrote:
>>>> after reading Heikki Linnakangas presentati
On Fri, Apr 4, 2014 at 5:29 PM, Greg Stark wrote:
> Two questions I have:
>
> 1) Would it make more sense to use a floating point instead of an integer? I
> saw a need for a function like this when I was looking into doing GPU sorts.
> But GPUs expect floating point values.
In the context of thi
On Wed, Apr 16, 2014 at 4:22 AM, Peter Geoghegan wrote:
>
> I don't want to dismiss what you're saying about heating and cooling
> being unrelated, but I don't find the conclusion that not everything
> can be hot obvious. Maybe "heat" should be relative rather than
> absolute, and maybe that's act
On Mon, Apr 21, 2014 at 8:07 PM, David G Johnston
wrote:
> Jim Nasby-2 wrote
>>> I feel that if there is no memory pressure, frankly it doesnt matter much
>>> about what gets out and what not. The case I am specifically targeting is
>>> when the clocksweep gets to move about a lot i.e. high memory
On Tue, Apr 22, 2014 at 8:19 AM, Florian Weimer wrote:
> Feedback in this thread was, "we want something like this in libpq, but not
> the thing you proposed". But there have been no concrete counter-proposals,
> and some of the responses did not take into account the inherent
> complexities of r
On Tue, Apr 22, 2014 at 3:45 PM, Florian Weimer wrote:
> On 01/03/2014 06:06 PM, Claudio Freire wrote:
>
>> Per-query expectations could be such a thing. And it can even work with
>> PQexec:
>>
>> PQexec(con, "SELECT nextval('a_id_seq') FROM genera
On Mon, Apr 28, 2014 at 12:52 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Abhijit Menon-Sen writes:
>> > In the past, we've had situations where "everything is hung" turned out
>> > to be because of a script that ran manual VACUUM that was holding some
>> > lock. It's admittedly not a huge pro
On Wed, May 28, 2014 at 6:51 PM, Peter Geoghegan wrote:
> Have you thought about things like specialized prefetching for nested
> loop joins?
Currently, such a thing would need some non-trivial changes to the
execution nodes, I believe.
For nestloop, correct me if I'm wrong, but index scan nodes
El 28/05/2014 22:12, "Peter Geoghegan" escribió:
>
> On Wed, May 28, 2014 at 5:59 PM, Claudio Freire
wrote:
> > For nestloop, correct me if I'm wrong, but index scan nodes don't have
> > visibility of the next tuple to be searched for.
>
> Nes
On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
wrote:
> On 05/29/2014 04:12 PM, John Lumby wrote:
>>
>> Thanks for looking at it!
>>
>>> Date: Thu, 29 May 2014 00:19:33 +0300
>>> From: hlinnakan...@vmware.com
>>> To: johnlu...@hotmail.com; pgsql-hackers@postgresql.org
>>> CC: klaussfre...@gma
On Thu, May 29, 2014 at 5:39 PM, Heikki Linnakangas
wrote:
> On 05/29/2014 11:34 PM, Claudio Freire wrote:
>>
>> On Thu, May 29, 2014 at 5:23 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 05/29/2014 04:12 PM, John Lumby wrote:
>>>>
On Thu, May 29, 2014 at 6:19 PM, Tom Lane wrote:
> Claudio Freire writes:
>> Didn't fix that, but the attached patch does fix regression tests when
>> scanning over index types other than btree (was invoking elog when the
>> index am didn't have ampeeknexttuple)
&
On Thu, May 29, 2014 at 6:43 PM, Claudio Freire wrote:
> On Thu, May 29, 2014 at 6:19 PM, Tom Lane wrote:
>> Claudio Freire writes:
>>> Didn't fix that, but the attached patch does fix regression tests when
>>> scanning over index types other than btree (was inv
On Thu, May 29, 2014 at 6:56 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Thu, May 29, 2014 at 6:43 PM, Claudio Freire
>> wrote:
>>> On Thu, May 29, 2014 at 6:19 PM, Tom Lane wrote:
>>>> "ampeeknexttuple"? That's a bit scary. It wo
On Thu, May 29, 2014 at 7:11 PM, John Lumby wrote:
>> Nonetheless, getting the next tid out of the index may involve stepping
>> to the next index page, at which point you've lost your interlock
>
> I think we are ok as peeknexttuple (yes bad name, sorry, can change it
> ...
> never advances to
On Thu, May 29, 2014 at 6:53 PM, John Lumby wrote:
> Well, as mentioned earlier, it is not broken. Whether it is efficient
> I am not sure.
> I have looked at the mutex in aio_suspend that you mentioned and I am not
> quite convinced that, if caller is not the original aio_read process,
> i
On Thu, May 29, 2014 at 7:26 PM, Claudio Freire wrote:
> 1) If it's the same process, wait for the full timeout (no looping).
> If you have to loop (EAGAIN or EINTR - which I just noticed you don't
> check for), that's ok.
Sorry, meant to say just looping on EINTR.
Ab
On Fri, May 30, 2014 at 4:15 AM, Heikki Linnakangas
wrote:
We don't want polling... And even if we did, calling aio_suspend() in a
way
that's known to be broken, in a loop, is a pretty crappy way of polling.
>>
>>
>> Well, as mentioned earlier, it is not broken. Whether it is
On Sat, May 31, 2014 at 9:44 PM, johnlumby wrote:
> I'll try to do some measuring of performance with:
> a) git head
> b) git head + patch as-is
> c) git head + patch without aio_suspend in foreign processes (just re-read)
> d) git head + patch with a lwlock (or whatever works) instead of aio_susp
I'm having trouble setting max_async_io_prefetchers in postgresql.conf
It says it cannot be changed.
Is that fixed at initdb time? (sounds like a bad idea if it is)
On Sun, Jun 8, 2014 at 11:12 PM, johnlumby wrote:
> updated version of patch compatible with git head of 140608,
> (adjusted proc
401 - 476 of 476 matches
Mail list logo
