On Sat, Nov 25, 2017 at 12:55 AM, Robert Haas wrote:
> On Tue, Nov 21, 2017 at 2:09 AM, Kyotaro HORIGUCHI
> wrote:
>> Yes, my concern here is how many column we can allow in a stats
>> view. I think I'm a bit too warried about that.
>
> I think that's a good thing to worry about. In the past, T
On Tue, Nov 21, 2017 at 5:38 PM, Peter Geoghegan wrote:
>> That having been said, I think the place where our plans most commonly
>> go wrong is where we incorrectly estimate the number of tuples by
>> multiple orders of magnitude - 100x is common, 1000x is common, a
>> million x is not uncommon,
Michael Paquier writes:
> On Sat, Nov 25, 2017 at 12:55 AM, Robert Haas wrote:
>> I think that's a good thing to worry about. In the past, Tom has
>> expressed reluctance to make stats tables that have a row per table
>> any wider at all, IIRC.
> Tom, any opinions to offer here? pg_stat_all_ta
On Wed, Nov 22, 2017 at 8:36 AM, Amit Kapila wrote:
>> remove-memory-leak-protection-v1.patch removes the memory leak
>> protection that Tom installed upon discovering that the original
>> version of tqueue.c leaked memory like crazy. I think that it
>> shouldn't do that any more, courtesy of
>>
On Sat, Nov 25, 2017 at 10:34 AM, Tom Lane wrote:
> If we could get rid of the copy-to-a-temporary-file technology for
> transferring the stats collector's data to backends, then this problem
> would probably vanish or at least get a lot less severe. But that seems
> like a nontrivial project. W
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
Robert Haas writes:
> Of course, the other obvious question is whether we really need a
> consistent snapshot, because that's bound to be pretty expensive even
> if you eliminate the I/O cost. Taking a consistent snapshot across
> all 100,000 tables in the database even if we're only ever going t
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
Hi,
On 11/25/2017 05:15 PM, Mark Dilger wrote:
>
>> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
>> wrote:
>>
>> Hi,
>>
>> Attached is an updated version of the patch, adopting the psql describe
>> changes introduced by 471d55859c11b.
>>
>> regards
>>
>> --
>> Tomas Vondra http:
Hackers, Alvaro,
In src/backend/statistics/extended_stats.c, in statext_store, there is a
section:
Datum values[Natts_pg_statistic_ext];
boolnulls[Natts_pg_statistic_ext];
boolreplaces[Natts_pg_statistic_ext];
memset(nulls, 1, Natts_pg_statistic_ext * sizeo
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
Hi Tomas,
In src/backend/statistics/dependencies.c, you have introduced a comment:
+ /*
+* build an
This patch adds \if support to pgbench, similar to psql's version added
in March.
This patch brings a consistent set of features especially when combined
with two other patches already in the (slow) CF process:
- https://commitfest.postgresql.org/10/596/ .. /15/985/
adds support for boo
Mark Dilger writes:
> It looks to me like Alvaro introduced this in the original version of the
> file which
> was created in commit 7b504eb282ca2f5104b5c00b4f05a3ef6bb1385b. Grep'ing
> through the code base, it seems the following would be more consistent with
> how these initializations are h
Hi,
On 11/25/2017 09:23 PM, Mark Dilger wrote:
>
>> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
>> wrote:
>>
>> Hi,
>>
>> Attached is an updated version of the patch, adopting the psql describe
>> changes introduced by 471d55859c11b.
>>
>> regards
>>
>> --
>> Tomas Vondra http:
On 11/25/2017 10:01 PM, Mark Dilger wrote:
>
>> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
>> wrote:
>>
>> Hi,
>>
>> Attached is an updated version of the patch, adopting the psql describe
>> changes introduced by 471d55859c11b.
>
> Hi Tomas,
>
> In src/backend/statistics/dependencies.c, you
On Sun, Nov 26, 2017 at 12:34 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sat, Nov 25, 2017 at 12:55 AM, Robert Haas wrote:
>>> I think that's a good thing to worry about. In the past, Tom has
>>> expressed reluctance to make stats tables that have a row per table
>>> any wider at all,
Michael Paquier writes:
> I am not arguing about skipped vacuuum data here (don't think much of
> it by the way), but of the number of index scans done by the last
> vacuum or autovacuum. This helps in tunning autovacuum_work_mem and
> maintenance_work_mem. The bar is still too high for that?
I'd
> On Nov 25, 2017, at 3:33 PM, Tomas Vondra
> wrote:
>
>
>
> On 11/25/2017 10:01 PM, Mark Dilger wrote:
>>
>>> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
>>> wrote:
>>>
>>> Hi,
>>>
>>> Attached is an updated version of the patch, adopting the psql describe
>>> changes introduced by 471d5
> On Nov 25, 2017, at 2:05 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> It looks to me like Alvaro introduced this in the original version of the
>> file which
>> was created in commit 7b504eb282ca2f5104b5c00b4f05a3ef6bb1385b. Grep'ing
>> through the code base, it seems the following would
On 11/26/2017 02:17 AM, Mark Dilger wrote:
>
>> On Nov 25, 2017, at 3:33 PM, Tomas Vondra
>> wrote:
>>
>>
>>
>> On 11/25/2017 10:01 PM, Mark Dilger wrote:
>>>
On Nov 18, 2017, at 12:28 PM, Tomas Vondra
wrote:
Hi,
Attached is an updated version of the patch, adop
Mark Dilger writes:
>> On Nov 25, 2017, at 3:33 PM, Tomas Vondra
>> wrote:
>> I might be missing something, but why would ereport be more appropriate
>> than elog? Ultimately, there's not much difference between elog(ERROR)
>> and ereport(ERROR) - both will cause a failure.
The core technical d
Mark Dilger wrote:
> I understand project policy to allow elog for error conditions that will be
> reported
> in "can't happen" type situations, similar to how an Assert would be used.
> For
> conditions that can happen through (mis)use by the user, ereport is
> appropriate.
> Not knowing whe
While doing some tests on REL_10_STABLE, I was getting run-time exceptions
at int8_avg_combine() at the following line:
state1->sumX = state2->sumX;
After some debugging, I noticed that palloc()’s alignment is 8-bytes, while
this statement (which moves a __int128 from one memory location to anoth
Hadi Moshayedi writes:
> While doing some tests on REL_10_STABLE, I was getting run-time exceptions
> at int8_avg_combine() at the following line:
> state1->sumX = state2->sumX;
> After some debugging, I noticed that palloc()’s alignment is 8-bytes, while
> this statement (which moves a __int128 f
Hi, all
Update version:
1. Re-base with head of master
2. Add some basic support for PGXS
After replacing submake-libpgport/submake-libpgfeutils with
$(stlib_pgport)/$(stlib_pgfeutils) in
Makefiles of client programs, I think, may be we should add static lib
dependency for PGXS.
I can think two
On Sun, Nov 26, 2017 at 11:07 AM, Mark Dilger wrote:
>
>> On Nov 25, 2017, at 2:05 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> It looks to me like Alvaro introduced this in the original version of the
>>> file which
>>> was created in commit 7b504eb282ca2f5104b5c00b4f05a3ef6bb1385b. Grep
28 matches
Mail list logo
