On Sun, May 29, 2011 at 3:36 PM, Joe Abbate wrote:
> Anyone interested in the tracker, please visit
> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
> feedback/input.
I think this illustrates exactly what we *don't* want to happen with a
bug tracker. We want the discussion to sta
On 05/29/2011 03:11 PM, Jeff Janes wrote:
If you use "pgbench -S -M prepared" at a scale where all data fits in
memory, most of what you are benchmarking is network/IPC chatter, and
table locking.
If you profile it, you'll find a large amount of the time is actually
spent doing more mundane th
2011/5/29 Tom Lane :
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
>> 2011/5/29 Tom Lane :
>>> OK, do you like the attached version of that logic? (Other fragments
>>> of the patch as before.)
>
>> The idea was that remove only one page from the VACUUM will prevent
>> relfrozenxid update and r
On 05/29/2011 02:01 PM, Stefan Kaltenbrunner wrote:
> feel free to reuse/edit the page as you like it(I have just removed the
> notice) - the "don't edit" thingy was added because people started to
> find the page via google (while searching for a tracker/bugreporting
> tool) and considered it offi
If you use "pgbench -S -M prepared" at a scale where all data fits in
memory, most of what you are benchmarking is network/IPC chatter, and
table locking. Which is fine if that is what you want to do. This
patch adds a new transaction type of -P, which does the same thing as
-S but it moves the m
On 05/29/2011 05:47 PM, Joe Abbate wrote:
> Hi Tom,
>
> On 05/29/2011 11:05 AM, Tom Lane wrote:
>> In the end, I think that requests for a tracker mostly come from people
>> who are not part of this community, or at least not part of its mailing
>> lists (which is about the same thing IMO).
>
> I
On Sun, May 29, 2011 at 10:35 PM, Tom Lane wrote:
> Pavan Deolasee writes:
>> I am sorry if I sounded terse above. But my gripe is that sometimes we
>> are too reluctant to listen to ideas and insist on producing some hard
>> numbers first which might take significant efforts. But we are not
>> e
Pavan Deolasee writes:
> I am sorry if I sounded terse above. But my gripe is that sometimes we
> are too reluctant to listen to ideas and insist on producing some hard
> numbers first which might take significant efforts. But we are not
> equally strict when such changes are introduced initially.
Hi Tom,
On 05/29/2011 11:05 AM, Tom Lane wrote:
> In the end, I think that requests for a tracker mostly come from people
> who are not part of this community, or at least not part of its mailing
> lists (which is about the same thing IMO).
I think that's a bit harsh. I assume you consider GSM a
On Sun, May 29, 2011 at 9:27 PM, Tom Lane wrote:
> Pavan Deolasee writes:
>> On Sun, May 29, 2011 at 8:10 PM, Tom Lane wrote:
>>> That would require proof, not just suggestion. Skipping pages will
>>> defeat the OS read-ahead algorithm, and so could easily cost more than
>>> reading them.
>
>>
On Fri, May 27, 2011 at 8:40 PM, Greg Stark wrote:
>
> Separately it's a bit strange that we actually have to visit the
> pages. We have all the information we need in the VM to determine
> whether there's a run of 32 vacuum-clean pages. Why can't we look at
> the next 32 pages and if they're all
Pavan Deolasee writes:
> On Sun, May 29, 2011 at 8:10 PM, Tom Lane wrote:
>> That would require proof, not just suggestion. Skipping pages will
>> defeat the OS read-ahead algorithm, and so could easily cost more than
>> reading them.
> My worry is what we have right now is also based on just a
On Sun, May 29, 2011 at 8:10 PM, Tom Lane wrote:
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
>> 2011/5/29 Tom Lane :
>>> OK, do you like the attached version of that logic? (Other fragments
>>> of the patch as before.)
>
>> The idea was that remove only one page from the VACUUM will prevent
Peter Eisentraut writes:
> That doesn't mean that better integration cannot be worked on later, but
> this illusion that a bug tracker must have magical total awareness of
> the entire flow of information in the project from day one is an
> illusion and has blocked this business for too long IMO.
On Sun, May 29, 2011 at 5:04 AM, Noah Misch wrote:
> What risks arise from unconditionally allowing these calls for the same user's
> backends? `pg_cancel_backend' ought to be safe enough; the user always has
> access to the standard cancellation protocol, making the SQL interface a mere
> conven
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> 2011/5/29 Tom Lane :
>> OK, do you like the attached version of that logic? (Other fragments
>> of the patch as before.)
> The idea was that remove only one page from the VACUUM will prevent
> relfrozenxid update and reltuples (and relpages) update.
On Wed, May 25, 2011 at 10:07:45PM +0300, Peter Eisentraut wrote:
> On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
> > Enthusiastic +1 for this concept. There's at least one rough edge: it
> > fails if
> > you have another postmaster running on port 5432.
>
> This has now been addressed: p
On sön, 2011-05-29 at 03:23 +, Greg Sabino Mullane wrote:
> My own bare bones wish list for such a tracker is:
>
> * Runs on Postgres
> * Has an email interface
I will add
* Free/open source software
to that.
Here is a list to choose from:
http://en.wikipedia.org/wiki/Comparison_of_issue_t
On sön, 2011-05-29 at 00:04 -0400, Tom Lane wrote:
> Many, many, many bug issues are not associated with a bug report
> submitted through the web interface. People mail stuff to pgsql-bugs
> manually, or issues turn up in threads on other lists. If a tracker
> can only find things submitted throu
On Sat, May 28, 2011 at 01:44:20PM -0400, Josh Kupershmidt wrote:
> Anssi and I posted some initial feedback on the patch's goals earlier.
> I would like to ultimately see users have the capability to
> pg_cancel_backend() their own queries. But I could at least conceive
> of others not wanting thi
On 05/29/2011 06:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 28, 2011 at 11:23 PM, Greg Sabino Mullane
>> wrote:
>>> My own bare bones wish list for such a tracker is:
>>>
>>> * Runs on Postgres
>>> * Has an email interface
>>>
>>> Make no mistake, whichever we choose, the care o
2011/5/29 Tom Lane :
> Greg Stark writes:
>> On Sat, May 28, 2011 at 12:01 PM, Tom Lane wrote:
>>> I also found that Greg was right in thinking that it would help if we
>>> tweaked lazy_scan_heap to not always scan the first
>>> SKIP_PAGES_THRESHOLD-1 pages even if they were
>>> all_visible_accor
On Sat, May 28, 2011 at 09:33:09PM -0400, Robert Haas wrote:
> On Fri, May 27, 2011 at 6:19 AM, Noah Misch wrote:
> >> So, it's ok to have a log item that is replayed only if
> >>
> >> WalRcvInProgress()
> >>
> >> is true?
> >
> > No, that checks for WAL streaming in particular. ?A log-shipping st
23 matches
Mail list logo
