I wrote:
> I'm still feeling a bit annoyed with the behavior of the stats machinery
> (pgstat_initstats and related macros).
> ... That means more UDP traffic and more work for
> the stats collector. gprof won't show the resulting overhead since
> it doesn't know anything about kernel-level overhe
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Applied along with some other hacking to reduce the costs of the
>> lower-level functions that this example shows to be inefficient.
>> They'd still be slow in large queries, whether CE applies or not.
> BIG diff
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> Applied along with some other hacking to reduce the costs of the
>> lower-level functions that this example shows to be inefficient.
>> They'd still be slow in large queries, whether CE applies or not.
>
> BI
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Applied along with some other hacking to reduce the costs of the
> lower-level functions that this example shows to be inefficient.
> They'd still be slow in large queries, whether CE applies or not.
BIG difference. The case that caused swapping and took
Gregory Stark <[EMAIL PROTECTED]> writes:
> I think there's still a problem here with some kind of n^2 behaviour for
> appends of very wide tables but I haven't quite nailed it yet. In any case is
> there any reason not to make the following small change to move the constraint
> exclusion ahead of
Gregory Stark <[EMAIL PROTECTED]> writes:
> Following up on some complaints we've had about extremely large plan times for
> large partitioned tables I've been doing some profiling.
> % cumulative self self total
> time seconds secondscalls s/call s/c
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The SearchCatCache here is the one in get_attavgwidth called to estimate the
>> relation width.
>
> Hmm, that information is supposed to be cached ... could you provide the
> test case?
This case caused my machi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The SearchCatCache here is the one in get_attavgwidth called to estimate the
>> relation width.
>
> Hmm, that information is supposed to be cached ... could you provide the
> test case?
Cached meaning it's stor
Gregory Stark <[EMAIL PROTECTED]> writes:
> The SearchCatCache here is the one in get_attavgwidth called to estimate the
> relation width.
Hmm, that information is supposed to be cached ... could you provide the
test case?
> The first thing that comes to mind is that we're doing the
> constraint_
Following up on some complaints we've had about extremely large plan times for
large partitioned tables I've been doing some profiling. I've constructed a
situation where it takes upwards of 30 seconds to plan a simple query like:
postgres=# explain select * from a where i between 999 and 1001;
10 matches
Mail list logo
