Hi, hackers,
The attached is a patch to improve compression speeds with loss of
compression ratios in backend/utils/adt/pg_lzcompress.c. Recent
modern compression techniques like google LZ4 and Snappy inspreid
me to write this patch. Thre are two points of my patch:
1. Skip at most 255 literals t
Jon Nelson writes:
> On Sun, Jan 6, 2013 at 4:14 AM, Simon Riggs wrote:
>> FKs are enforced by triggers currently. Adding triggers requires
>> AccessExclusiveLock because of catalog visibility issues; you are
>> right that a lower lock is eventually possible.
> I've read and re-read this a few t
>>> AFAIK the "5 second" logging is much quieter in most cases (and a bit
>>> more verbose when the initialization gets very slower), so I think the
>>> "quiet" logging is not a bad match although maybe there's a better name.
>>>
>>> This change (adding the elapsed/remaining fields to the original
On Sun, Jan 6, 2013 at 4:14 AM, Simon Riggs wrote:
> On 6 January 2013 03:08, Jon Nelson wrote:
>> When adding a foreign key constraint on tableA which references
>> tableB, why is an AccessExclusive lock on tableB necessary? Wouldn't a
>> lock that prevents writes be sufficient, or does PostgreS
* Stephen Frost wrote:
>
> Yes, and have the actual 'description' field (as it's variable) at the
> end of the catalog.
>
> Regarding the semantics of it- I was thinking about how directories and
> unix files work. Basically, adding or removing a sub-object would
> update the alter time on the ob
On 6 January 2013 23:03, Tom Lane wrote:
> Simon Riggs writes:
>> On 6 January 2013 18:58, Tom Lane wrote:
>>> IIRC, one of my very first attempts to deal with this was to charge
>>> random_page_cost per level of index descended. This was such a horrid
>>> overestimate that it never went anywhe
I wrote:
> [ slightly bogus graph ]
Ooops, it seems the ^ operator doesn't do what I thought in gnuplot.
Here's a corrected version.
regards, tom lane
<>set terminal png small color
set output 'new_fudge.png'
set xlabel "Index tuples"
set ylabel "Added cost"
set logscale
Simon Riggs writes:
> On 6 January 2013 18:58, Tom Lane wrote:
>> IIRC, one of my very first attempts to deal with this was to charge
>> random_page_cost per level of index descended. This was such a horrid
>> overestimate that it never went anywhere. I think that reflects that in
>> practical
On 9 August 2012 10:45, Simon Riggs wrote:
> On 22 June 2012 05:03, Kyotaro HORIGUCHI
> wrote:
>
>>I hope this is promising.
>
> I've reviewed this and thought about it over some time.
I've been torn between the need to remove the checkpoint for speed and
being worried about the implications
On 5 January 2013 19:15, Tom Lane wrote:
>> We need a full "one-shot" concept linking the planner and executor for
>> all sorts of reasons, not just this one. We can discuss the
>> practicality of individual optimizations but the linkage should be
>> clear throughout the whole infrastructure.
>
>
On 6 January 2013 18:58, Tom Lane wrote:
> Simon Riggs writes:
>> On 5 January 2013 22:18, Tom Lane wrote:
>>> No. The argument is that if we don't have some such correction, the
>>> planner is liable to believe that different-sized indexes have *exactly
>>> the same cost*, if a given query wou
Simon Riggs writes:
> On 5 January 2013 22:18, Tom Lane wrote:
>> No. The argument is that if we don't have some such correction, the
>> planner is liable to believe that different-sized indexes have *exactly
>> the same cost*, if a given query would fetch the same number of index
>> entries.
>
On 6 January 2013 16:29, Jeff Janes wrote:
> Worse, this over-punishment of bloat is more likely to penalize partial
> indexes. Since they are vacuumed on the table's schedule, not their own
> schedule, they likely get vacuumed less often relative to the amount of
> turn-over they experience an
On 5 January 2013 22:18, Tom Lane wrote:
>> But I am wondering if it should be present at all in 9.3. When it was
>> introduced, the argument seemed to be that smaller indexes might be easier
>> to keep in cache.
>
> No. The argument is that if we don't have some such correction, the
> planner
Jeff Janes writes:
> On Saturday, January 5, 2013, Tom Lane wrote:
>> Jeff Janes > writes:
>>> One thing which depends on the index size which, as far as I can tell, is
>>> not currently being counted is the cost of comparing the tuples all the way
>>> down the index. This would be proportional t
On Saturday, January 5, 2013, Tom Lane wrote:
> Jeff Janes > writes:
> > [moved to hackers]
> > On Wednesday, December 5, 2012, Tom Lane wrote:
> >> Hm. To tell you the truth, in October I'd completely forgotten about
> >> the January patch, and was thinking that the 1/1 cost had a lot
> >> o
On 6.1.2013 10:35, Tatsuo Ishii wrote:
>>> If we do so, probably '-q' is not appropeate option name any more,
>>> since the only difference between old logging and new one is, the
>>> former is printed every 1 lines while the latter is every 5
>>> seconds, which is not really "quiet". What do y
On 6 January 2013 03:08, Jon Nelson wrote:
> When adding a foreign key constraint on tableA which references
> tableB, why is an AccessExclusive lock on tableB necessary? Wouldn't a
> lock that prevents writes be sufficient, or does PostgreSQL have to
> modify *both* tables in some fashion? I'm us
>> If we do so, probably '-q' is not appropeate option name any more,
>> since the only difference between old logging and new one is, the
>> former is printed every 1 lines while the latter is every 5
>> seconds, which is not really "quiet". What do you think?
>
> AFAIK the "5 second" logging
19 matches
Mail list logo
