On Fri, Jun 17, 2011 at 8:15 PM, Robert Haas wrote:
> On Fri, Jun 17, 2011 at 3:08 PM, Simon Riggs wrote:
>> Not so. The extra locking would only occur on the first lock
>> acquisition after DDL operations occur. If that was common then your
>> other performance patch would not be an effective op
On Fri, Jun 17, 2011 at 3:08 PM, Simon Riggs wrote:
> Not so. The extra locking would only occur on the first lock
> acquisition after DDL operations occur. If that was common then your
> other performance patch would not be an effective optimisation. There
> is no additional locking from what I'v
On Fri, Jun 17, 2011 at 2:44 PM, Tom Lane wrote:
> Hmm, yeah, I think this idea is probably better than mine, just because
> of the less dubious semantics. I don't see how you'd make it work for
> generic MVCC scans, because the behavior will be "the database state as
> of some hard-to-predict ti
On Fri, Jun 17, 2011 at 7:24 PM, Robert Haas wrote:
> On Fri, Jun 17, 2011 at 1:22 PM, Tom Lane wrote:
>> Yeah, this seems like a possibly workable direction to explore. I like
>> this better than what Simon is proposing, because it would fix the
>> generic issue for all types of catalog Snapsh
Robert Haas writes:
> On Fri, Jun 17, 2011 at 1:22 PM, Tom Lane wrote:
>> Yeah. After mulling it for awhile, what about this idea: we could
>> redefine SnapshotNow as a snapshot type that includes a list of
>> transactions-in-progress, somewhat like an MVCC snapshot, but we don't
>> fill that li
On Fri, Jun 17, 2011 at 1:22 PM, Tom Lane wrote:
> Yeah, this seems like a possibly workable direction to explore. I like
> this better than what Simon is proposing, because it would fix the
> generic issue for all types of catalog SnapshotNow scans.
It would also avoid adding more lock manager
Robert Haas writes:
> On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
>> I believe that this is fundamentally unavoidable so long as we use
>> SnapshotNow to read catalogs --- which is something we've talked about
>> changing, but it will require a pretty major R&D effort to make it
>> happen.
On Fri, Jun 17, 2011 at 9:32 AM, simon wrote:
> On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane wrote:
>
>> 2. In response, some other backend starts to reload its relcache entry
>> for pgbench_accounts when it begins its next command. It does an
>> indexscan with SnapshotNow on pg_class to find the
On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane wrote:
> 2. In response, some other backend starts to reload its relcache entry
> for pgbench_accounts when it begins its next command. It does an
> indexscan with SnapshotNow on pg_class to find the updated pg_class row.
>
> 3. Meanwhile, some third ba
On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
> I believe that this is fundamentally unavoidable so long as we use
> SnapshotNow to read catalogs --- which is something we've talked about
> changing, but it will require a pretty major R&D effort to make it
> happen. In the meantime, we have to
On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane wrote:
> In typical cases where both versions of the row are on the same page,
> the window for the concurrent commit to happen is very narrow --- that's
> why you need so many clients to make it happen easily. With enough
> clients there's a good chanc
If you set up a pgbench test case that hits the database with a lot of
concurrent selects and non-exclusive-locking ALTER TABLEs, 9.1 soon
falls over. For example:
$ cat foo.script
alter table pgbench_accounts set (fillfactor = 100);
SELECT abalance FROM pgbench_accounts WHERE aid = 525212;
$ cr
201 - 212 of 212 matches
Mail list logo
