On 06.06.2011 07:12, Robert Haas wrote:
I did some further investigation of this. It appears that more than
99% of the lock manager lwlock traffic that remains with this patch
applied has locktag_type == LOCKTAG_VIRTUALTRANSACTION. Every SELECT
statement runs in a separate transaction, and for
On Jun 4, 2011, at 3:56 AM, Greg Stark wrote:
> On Thu, Jun 2, 2011 at 8:58 PM, Jim Nasby wrote:
>>
>> I'm torn between whether the type should store the original time or the
>> original time converted to GMT.
>
> This is the wrong way to think about it. We *never* store time
> "converted to GM
On Sun, Jun 5, 2011 at 8:33 AM, Robert Haas wrote:
> We've occasionally seen problems with VACUUM getting stuck for failure
> to acquire a cleanup lock due to, for example, a cursor holding a pin
> on the buffer page. In the worst case, this can cause an undetected
> deadlock, if the backend hold
On Jun 6, 2011, at 1:00 AM, Robert Haas wrote:
> On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
> wrote:
>> On Sun, Jun 5, 2011 at 12:03, Robert Haas wrote:
>>> If other buffer pins do exist, then we can't
>>> defragment the page, but that doesn't mean no useful work can be done:
>>> we can st
On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
wrote:
> On Sun, Jun 5, 2011 at 12:03, Robert Haas wrote:
>> If other buffer pins do exist, then we can't
>> defragment the page, but that doesn't mean no useful work can be done:
>> we can still mark used line pointers dead, or dead line pointers
On Sun, Jun 05, 2011 at 12:45:41PM -0500, Kevin Grittner wrote:
> Is this possible? If a transaction gets its snapshot while OID of N
> is assigned to relation X, can that transaction wind up seeing an OID
> of N as a reference to relation Y? If not, there aren't any false
> positives possible.
Pavel Stehule wrote:
2011/6/6 Darren Duncan :
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
it s
2011/6/6 Darren Duncan :
> Jeff Davis wrote:
>>
>> I'd like to take another look at Range Types and whether part of it
>> should be an extension. Some of these issues relate to extensions in
>> general, not just range types.
>>
>> First of all, what are the advantages to being in core?
it should b
Tom Lane Monday 06 of June 2011 04:07:41
> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> > I've got idea to auto adjust send buffer size to size of TCP congention
> > window. Will this increase performance and in which way. I suppose
> > throughput may be increased, but latency decreased. What do Y
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
I believe that ranges aka intervals are widely usefu
On Sun, Jun 5, 2011 at 12:03, Robert Haas wrote:
> If other buffer pins do exist, then we can't
> defragment the page, but that doesn't mean no useful work can be done:
> we can still mark used line pointers dead, or dead line pointers
> unused. We cannot defragment, but that can be done either b
On Sun, Jun 5, 2011 at 10:16 PM, Robert Haas wrote:
> I'm definitely interested in investigating what to do
> about that, but I don't think it's this patch's problem to fix all of
> our lock manager bottlenecks.
I did some further investigation of this. It appears that more than
99% of the lock
Noah Misch writes:
> On Sun, Jun 05, 2011 at 02:17:00PM -0400, Tom Lane wrote:
>> Attached are two versions of a patch to fix this. The second one
>> modifies the code that tracks what's "pending" as per the above thought.
>> I'm not entirely sure which one I like better ... any comments?
> +1 f
On Sun, 2011-06-05 at 15:09 -0400, Tom Lane wrote:
> so once we've set the index as the currentlyReindexedIndex, there's
> no need for it still to be in pendingReindexedIndexes.
OK. The second version of the patch looks good to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
On Sun, Jun 5, 2011 at 5:46 PM, Robert Haas wrote:
> Could you compile with LWLOCK_STATS, rerun these tests, total up the
> "blk" numbers by LWLockId, and post the results? (Actually, totalling
> up the shacq and exacq numbers would be useful as well, if you
> wouldn't mind.)
I did this on the l
"Kevin Grittner" wrote:
> Maybe I should submit a patch without added complexity of the
> scheduled cleanup and we can discuss that as a separate patch?
Here's a patch which adds the missing support for DDL. Cleanup of
predicate locks at commit time for transactions which ran DROP TABLE
or TRUNCA
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> I've got idea to auto adjust send buffer size to size of TCP congention
> window. Will this increase performance and in which way. I suppose throughput
> may be increased, but latency decreased. What do You think?
I think if that makes any difference
On Sun, Jun 05, 2011 at 02:17:00PM -0400, Tom Lane wrote:
> I wrote:
> > Noah Misch writes:
> >> Sounds reasonable. Need to remove the index from pendingReindexedIndexes,
> >> not
> >> just call ResetReindexProcessing().
>
> > [ looks again... ] Uh, right. I was thinking that the pending list
On Sun, Jun 5, 2011 at 1:06 PM, Josh Kupershmidt wrote:
> On Sun, Jun 5, 2011 at 10:21 AM, Gurjeet Singh
> wrote:
> > On Sat, May 21, 2011 at 11:59 AM, Josh Kupershmidt
> > wrote:
>
> > Tweaks applied, but omitted the C variable names as I don't think that
> adds
> > much value.
>
> Your reword
On Sun, Jun 5, 2011 at 4:01 PM, Stefan Kaltenbrunner
wrote:
> On 06/05/2011 09:12 PM, Heikki Linnakangas wrote:
>> On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
>>> and one for the -j80 case(also patched).
>>>
>>>
>>> 485798 48.9667 postgres s_lock
>>> 60327 6.0808 postg
Tom Lane writes:
> Yes. I think the appropriate problem statement is "provide streaming
> access to large field values, as an alternative to just fetching/storing
> the entire value at once". I see no good reason to import the entire
> messy notion of LOBS/CLOBS. (The fact that other databases
On 06/05/2011 09:12 PM, Heikki Linnakangas wrote:
> On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
>> and one for the -j80 case(also patched).
>>
>>
>> 485798 48.9667 postgres s_lock
>> 60327 6.0808 postgres LWLockAcquire
>> 57049 5.7503 postgres
Hi,
I've got idea to auto adjust send buffer size to size of TCP congention
window. Will this increase performance and in which way. I suppose throughput
may be increased, but latency decreased. What do You think?
Regards,
Radek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
and one for the -j80 case(also patched).
485798 48.9667 postgres s_lock
60327 6.0808 postgres LWLockAcquire
57049 5.7503 postgres LWLockRelease
18357 1.8503 postgres
Jeff Davis writes:
> On Sun, 2011-06-05 at 14:17 -0400, Tom Lane wrote:
>> Attached are two versions of a patch to fix this. The second one
>> modifies the code that tracks what's "pending" as per the above thought.
>> I'm not entirely sure which one I like better ... any comments?
> I think I'm
On 06/03/2011 03:17 PM, Robert Haas wrote:
[...]
>
> As you can see, this works out to a bit more than a 4% improvement on
> this two-core box. I also got access (thanks to Nate Boley) to a
> 24-core box and ran the same test with scale factor 100 and
> shared_buffers=8GB. Here are the results o
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
1. ANYRANGE + CREATE TYPE ... AS RANGE
--
On Sun, 2011-06-05 at 14:17 -0400, Tom Lane wrote:
> Attached are two versions of a patch to fix this. The second one
> modifies the code that tracks what's "pending" as per the above thought.
> I'm not entirely sure which one I like better ... any comments?
I think I'm missing something simple:
I wrote:
> Noah Misch writes:
>> Sounds reasonable. Need to remove the index from pendingReindexedIndexes,
>> not
>> just call ResetReindexProcessing().
> [ looks again... ] Uh, right. I was thinking that the pending list was
> just "pending" and not "in progress" indexes. I wonder if we sho
Hello all
I am working on new diagnostics fields in errors - CONSTRAINT_NAME,
SCHEMA_NAME, TABLE_NAME and COLUMN_NAME.
These fields is shown when verbosity mode is active. Actually this
works for table constraints, not null constraint and for RI
constraints.
postgres=# delete from xxx;
ERROR:
> Heikki Linnakangas wrote:
> On 03.06.2011 23:44, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>
>>> I think you'll need to just memorize the lock deletion command in
>>> a backend-local list, and perform the deletion in a post-commit
>>> function.
>>
>> Hmm. As mentioned earlier in the th
On Sun, Jun 5, 2011 at 10:21 AM, Gurjeet Singh wrote:
> On Sat, May 21, 2011 at 11:59 AM, Josh Kupershmidt
> wrote:
> Tweaks applied, but omitted the C variable names as I don't think that adds
> much value.
Your rewordings are fine, but the the article "the" is missing in a
few spots, e.g.
*
Noah Misch writes:
> On Sat, Jun 04, 2011 at 05:49:31PM -0400, Tom Lane wrote:
>> So in short, I'm thinking move lines 1760-1772 (in HEAD) of index.c to
>> the end of index_build(), then insert a ResetReindexProcessing() call in
>> front of them; or maybe only do ResetReindexProcessing there if we
On Sat, May 21, 2011 at 11:59 AM, Josh Kupershmidt wrote:
> On Fri, May 20, 2011 at 2:35 PM, Gurjeet Singh
> wrote:
> > On Sat, May 14, 2011 at 5:03 PM, Josh Kupershmidt
> > wrote:
> > Thanks a lot for the review. My responses are inline below.
>
> Thanks for the fixes. Your updated patch is sen
Hi,
> On 05/07/2011 03:32 AM, Mitsuru IWASAKI wrote:
> > For 1, I've just finish my work. The latest patch is available at:
> > http://people.freebsd.org/~iwasaki/postgres/buffer-cache-hibernation-postgresql-20110507.patch
> >
>
> Reminder here--we can't accept code based on it being publish
35 matches
Mail list logo
