On Sun, Jun 23, 2019 at 06:56:53PM +0100, Dean Rasheed wrote:
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
On Fri, May 10, 2019 at 10:19:44AM +0100, Dean Rasheed wrote:
>While working on 1aebfbea83c, I noticed that the new multivariate MCV
>stats feature suffers from the same problem,
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
>
> On Fri, May 10, 2019 at 10:19:44AM +0100, Dean Rasheed wrote:
> >While working on 1aebfbea83c, I noticed that the new multivariate MCV
> >stats feature suffers from the same problem, and also the original
> >problems that were fixed in
On Thu, Jun 13, 2019 at 07:37:45PM +0200, Tomas Vondra wrote:
...
OK, attached are patches fixing the issues reported by you and John
Naylor, and squashing the parts into just two patches (catalog split and
pg_stats_ext). Barring objections, I'll push those tomorrow.
I've renamed columns in
On Mon, Jun 10, 2019 at 02:32:04PM +0100, Dean Rasheed wrote:
On Thu, 6 Jun 2019 at 21:33, Tomas Vondra wrote:
Hi,
Attached are three patches tweaking the stats - two were already posted
in this thread, the third one is just updating docs.
1) 0001 - split pg_statistic_ext into definition +
On Fri, Jun 7, 2019 at 4:33 AM Tomas Vondra
wrote:
> 2) 0002 - update sgml docs to reflect changes from 0001
There is some copypasta here in the new section referring to the old catalog:
+
+ pg_statistic_ext_data
+
+
+ pg_statistic_ext
+
+
+
+ The catalog pg_statistic_ext
+ holds
On Thu, 6 Jun 2019 at 21:33, Tomas Vondra wrote:
>
> Hi,
>
> Attached are three patches tweaking the stats - two were already posted
> in this thread, the third one is just updating docs.
>
> 1) 0001 - split pg_statistic_ext into definition + data
>
> This is pretty much the patch Dean posted
Hi,
Attached are three patches tweaking the stats - two were already posted
in this thread, the third one is just updating docs.
1) 0001 - split pg_statistic_ext into definition + data
This is pretty much the patch Dean posted some time ago, rebased to
current master (fixing just minor
On Mon, May 20, 2019 at 04:09:24PM +0100, Dean Rasheed wrote:
On Mon, 20 May 2019 at 14:32, Tom Lane wrote:
Dean Rasheed writes:
> On Sun, 19 May 2019 at 23:45, Tomas Vondra
wrote:
>> Oh, right. It still has the disadvantage that it obfuscates the actual
>> data stored in the
On Mon, 20 May 2019 at 14:32, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Sun, 19 May 2019 at 23:45, Tomas Vondra
> > wrote:
> >> Oh, right. It still has the disadvantage that it obfuscates the actual
> >> data stored in the pg_stats_ext_data (or whatever would it be called),
> >> so e.g.
On Mon, May 20, 2019 at 09:32:24AM -0400, Tom Lane wrote:
Dean Rasheed writes:
On Sun, 19 May 2019 at 23:45, Tomas Vondra wrote:
Oh, right. It still has the disadvantage that it obfuscates the actual
data stored in the pg_stats_ext_data (or whatever would it be called),
so e.g. functions
Dean Rasheed writes:
> On Sun, 19 May 2019 at 23:45, Tomas Vondra
> wrote:
>> Oh, right. It still has the disadvantage that it obfuscates the actual
>> data stored in the pg_stats_ext_data (or whatever would it be called),
>> so e.g. functions would have to do additional checks to make sure it
On Sun, 19 May 2019 at 23:45, Tomas Vondra wrote:
>
> Oh, right. It still has the disadvantage that it obfuscates the actual
> data stored in the pg_stats_ext_data (or whatever would it be called),
> so e.g. functions would have to do additional checks to make sure it
> actually is the right
On Sun, May 19, 2019 at 02:14:54PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
No, wait, scratch that. We could fold the three existing types
pg_ndistinct, pg_dependencies, pg_mcv_list into one new type, say
"pg_stats_ext_data", where
Tomas Vondra writes:
> On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
>> No, wait, scratch that. We could fold the three existing types
>> pg_ndistinct, pg_dependencies, pg_mcv_list into one new type, say
>> "pg_stats_ext_data", where the actual storage would need to have an
>> ID
On Sun, 19 May 2019 at 15:28, Tom Lane wrote:
>
> > I wonder ... another way we could potentially do this is
>
> > create table pg_statistic_ext_data(
> > stxoid oid, -- OID of owning pg_statistic_ext entry
> > stxkind char, -- what kind of data
> > stxdata bytea -- the data, in some
On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
I wrote:
I wonder ... another way we could potentially do this is
create table pg_statistic_ext_data(
stxoid oid, -- OID of owning pg_statistic_ext entry
stxkind char, -- what kind of data
stxdata bytea -- the data, in
I wrote:
> I wonder ... another way we could potentially do this is
> create table pg_statistic_ext_data(
> stxoid oid, -- OID of owning pg_statistic_ext entry
> stxkind char, -- what kind of data
> stxdata bytea -- the data, in some format or other
> );
> The advantage of this way
Dean Rasheed writes:
> I think we shouldn't risk trying to get this into beta1, but let's try
> to get it done as soon as possible after that.
Agreed.
> \d pg_statistic_ext
> Table "pg_catalog.pg_statistic_ext"
> Column|Type| Collation | Nullable | Default
>
On Sun, 19 May 2019 at 00:48, Stephen Frost wrote:
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Tomas Vondra writes:
> >
> > > I think we have four options - rework it before beta1, rework it after
> > > beta1, rework it in PG13 and leave it as it is now.
> >
> > Yup, that's about what the
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Tomas Vondra writes:
> > On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
> >> Tomas Vondra writes:
> >>> But that's not an issue intruduced by PG12, it works like that even for
> >>> the extended statistics introduced in PG10.
>
>
Tomas Vondra writes:
> On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
>> Tomas Vondra writes:
>>> But that's not an issue intruduced by PG12, it works like that even for
>>> the extended statistics introduced in PG10.
>> Yeah, but no time like the present to fix it if it's wrong ...
On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
It seems like what we need here is to have a separation between the
*definition* of a stats object
Tomas Vondra writes:
> On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
>>> On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
It seems like what we need here is to have a separation between the
*definition* of a stats object (which is what pg_dump needs access
to) and
On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
Hi,
On May 18, 2019 8:43:29 AM PDT, Dean Rasheed wrote:
On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
Dean Rasheed writes:
> On the other hand, pg_dump relies on pg_statistic_ext to work out
> which extended statistics objects
Hi,
On May 18, 2019 8:43:29 AM PDT, Dean Rasheed wrote:
>On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
>>
>> Dean Rasheed writes:
>> > On the other hand, pg_dump relies on pg_statistic_ext to work out
>> > which extended statistics objects to dump. If we were to change
>that
>> > to use
On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On the other hand, pg_dump relies on pg_statistic_ext to work out
> > which extended statistics objects to dump. If we were to change that
> > to use pg_stats_ext, then a user dumping a table with RLS using the
> >
Dean Rasheed writes:
> On the other hand, pg_dump relies on pg_statistic_ext to work out
> which extended statistics objects to dump. If we were to change that
> to use pg_stats_ext, then a user dumping a table with RLS using the
> --enable-row-security flag wouldn't get any extended statistics
>
On Sat, 18 May 2019 at 10:11, Dean Rasheed wrote:
>
> On Fri, 17 May 2019 at 21:29, Andres Freund wrote:
> >
> > On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> > > 5). Some columns from pg_statistic_ext have to be made visible for
> > > psql \d to work. Basically, it needs to be able to
On Fri, 17 May 2019 at 21:29, Andres Freund wrote:
>
> On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> > 5). Some columns from pg_statistic_ext have to be made visible for
> > psql \d to work. Basically, it needs to be able to query for the
> > existence of extended statistics, but it doesn't
Hi,
On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> 5). Some columns from pg_statistic_ext have to be made visible for
> psql \d to work. Basically, it needs to be able to query for the
> existence of extended statistics, but it doesn't need to see the
> actual statistical data. Of course, we
On Thu, May 16, 2019 at 02:28:03PM +0100, Dean Rasheed wrote:
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
Yeah. I suggest we add a simple pg_stats_ext view, similar to pg_stats.
It would:
(1) translate the schema / relation / attribute names
I don't see why translating column
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
>
> Yeah. I suggest we add a simple pg_stats_ext view, similar to pg_stats.
> It would:
>
> (1) translate the schema / relation / attribute names
>
> I don't see why translating column indexes to names would be fiddly.
> It's a matter of
On Fri, May 10, 2019 at 10:19:44AM +0100, Dean Rasheed wrote:
While working on 1aebfbea83c, I noticed that the new multivariate MCV
stats feature suffers from the same problem, and also the original
problems that were fixed in e2d4ef8de8 and earlier --- namely that a
user can see values in the
While working on 1aebfbea83c, I noticed that the new multivariate MCV
stats feature suffers from the same problem, and also the original
problems that were fixed in e2d4ef8de8 and earlier --- namely that a
user can see values in the MCV lists that they shouldn't see (values
from tables that they
34 matches
Mail list logo
