Robert Haas writes:
> Yuck. Well, that's certainly a bug. What's weird is that I thought
> we had put logic into the join removal code to ignore deferrable
> constraints. Apparently not.
I poked around a bit more and could not find any evidence that we'd
ever done that. Ah well.
> I think ma
Robert Haas writes:
> On Fri, Oct 21, 2011 at 3:55 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Anyhow, here's the scoop. On my desktop machine running F14, running
>>> SELECT sum(1) FROM pgbench_accounts in a tight loop, 60 s worth of
>>> oprofile data:
>>> 176830 13.0801 postgres
On Thu, Oct 20, 2011 at 9:36 PM, Kyotaro HORIGUCHI
wrote:
> This must be the basis of the behavior of pg_utf8_verifier(), and
> pg_utf8_increment() has taken over it. It may be good to describe
> this origin of the special handling as comment of these functions
> to avoid this sort of confusion.
Thom Brown writes:
> Can I ask why it doesn't return the same snapshot ID each time?
> Surely it can't change since you can only export the snapshot of a
> serializable or repeatable read transaction?
No, that's incorrect. You can export from a READ COMMITTED transaction;
indeed, you'd more or l
On 10/23/2011 06:39 AM, Joshua D. Drake wrote:
On 10/22/2011 11:39 AM, nrdb wrote:
Are you willing to submit a patch for people to review? I am not sure
if the community would want this as backend code or not but it is
definitely something to discuss.
Yes! but I don't know what the procedur
On 10/23/2011 08:17 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
Any patch you submit will be subject to quite a bit of discussion so be
prepared for that. Also it will have to be portable to Windows.
The first question that's going to be asked is why you don't just use an
encrypted file sys
On 23 October 2011 00:25, Tom Lane wrote:
> Joachim Wieland writes:
>> [ synchronized snapshots patch ]
>
> Applied with, um, rather extensive editorialization.
>
> I'm not convinced that the SSI case is bulletproof yet, but it'll be
> easier to test with the code committed.
Can I ask why it doe
Dan Ports writes:
> On Wed, Oct 19, 2011 at 04:36:41PM -0400, Tom Lane wrote:
>> (2) as things stand, xact A need not be running in serializable mode ---
>> if B is serializable, does *that* break any assumptions?
> [taking these in opposite order]
> Yes, I think that's going to be a problem. Th
Joachim Wieland writes:
> [ synchronized snapshots patch ]
Applied with, um, rather extensive editorialization.
I'm not convinced that the SSI case is bulletproof yet, but it'll be
easier to test with the code committed.
regards, tom lane
--
Sent via pgsql-hackers mail
"Joshua D. Drake" writes:
> Any patch you submit will be subject to quite a bit of discussion so be
> prepared for that. Also it will have to be portable to Windows.
The first question that's going to be asked is why you don't just use an
encrypted file system, instead. Not every problem has to
Robert Haas writes:
> On Fri, Oct 21, 2011 at 10:57 PM, Jeff Janes wrote:
>> If count(*) could cause the index-only scan to happen in physical
>> order of the index, rather than logical order, that might be a big
>> win. Both for all in memory and for not-all-in-memory.
> That's an interesting
- Цитат от Tom Lane (t...@sss.pgh.pa.us), на 22.10.2011 в 19:19 -
> Andres Freund writes:
>> On Saturday, October 22, 2011 05:20:26 PM Tom Lane wrote:
>>> Huh? In the case he's complaining about, the index is all in RAM.
>>> Sequentiality of access is not an issue (at least not at the pa
On 10/23/2011 02:37 AM, Joshua D. Drake wrote:
On 10/21/2011 05:42 PM, nrdb wrote:
Hi,
I am new to this list. I haven't ever contributed code before, and have
no idea on how to do this.
I have made some changes to my copy of the 9.1.1 code that
encrypts/decrypts the database files on the fly
On 10/22/2011 11:39 AM, nrdb wrote:
Are you willing to submit a patch for people to review? I am not sure
if the community would want this as backend code or not but it is
definitely something to discuss.
Yes! but I don't know what the procedure is to do that.
http://wiki.postgresql.org/wi
On Fri, Oct 21, 2011 at 10:57 PM, Jeff Janes wrote:
>> Yeah, but it works out to fewer pages.
>
> But since those pages are already in RAM, why would it matter all that
> much? (Other than in the case of highly concurrent access, which you
> don't seem to be testing?)
Well, because memory access
Andres Freund writes:
> On Saturday, October 22, 2011 05:20:26 PM Tom Lane wrote:
>> Huh? In the case he's complaining about, the index is all in RAM.
>> Sequentiality of access is not an issue (at least not at the page
>> level --- within a page I suppose there could be cache-line effects).
> I
On Saturday, October 22, 2011 05:20:26 PM Tom Lane wrote:
> Andres Freund writes:
> > On Friday, October 21, 2011 08:14:12 PM Robert Haas wrote:
> >> On Fri, Oct 21, 2011 at 2:08 PM, Tom Lane wrote:
> >>> It's not "touching six times less data". It's touching the exact same
> >>> number of tuple
On 10/21/2011 05:42 PM, nrdb wrote:
Hi,
I am new to this list. I haven't ever contributed code before, and have
no idea on how to do this.
I have made some changes to my copy of the 9.1.1 code that
encrypts/decrypts the database files on the fly using AES256 cypher.
Very cool.
It passes
Simon Riggs writes:
> 1 *and* 4 please.
Given the lack of enthusiasm I'm not going to do anything about #4 now.
Somebody else can add it later.
> So, unless explicitly requested, an exported snapshot is limited to
> just one database. If explicitly requested to be transportable, we can
> use the
Andres Freund writes:
> On Friday, October 21, 2011 08:14:12 PM Robert Haas wrote:
>> On Fri, Oct 21, 2011 at 2:08 PM, Tom Lane wrote:
>>> It's not "touching six times less data". It's touching the exact same
>>> number of tuples either way, just index tuples in one case and heap
>>> tuples in t
On Fri, Oct 21, 2011 at 4:36 PM, Tom Lane wrote:
> I can see a few alternatives, none of them very pleasant:
>
> 1. Restrict exported snapshots to be loaded only by transactions running
> in the same database as the exporter. This would fix the problem, but
> it cuts out one of the main use-case
2011/10/22 Andres Freund
> On Friday, October 21, 2011 08:14:12 PM Robert Haas wrote:
> > On Fri, Oct 21, 2011 at 2:08 PM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> On Fri, Oct 21, 2011 at 1:18 PM, Tom Lane wrote:
> > >>> I don't know why you'd imagine that touching an index is free, or
On Friday, October 21, 2011 08:14:12 PM Robert Haas wrote:
> On Fri, Oct 21, 2011 at 2:08 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Fri, Oct 21, 2011 at 1:18 PM, Tom Lane wrote:
> >>> I don't know why you'd imagine that touching an index is free, or even
> >>> cheap, CPU-wise. The who
23 matches
Mail list logo
