On Thu, 2024-02-29 at 12:07 +0100, Dominique Devienne wrote:
> But I'm sure indexes on columns "not used at all in a statement" are
> eliminated early and easily/cheaply,
> w/o even getting into more complex consideration like statistics and co.
> Aren't they?
You may want a "SELECT count(*)
On Thu, Feb 29, 2024 at 11:58 AM Laurenz Albe
wrote:
> On Thu, 2024-02-29 at 10:55 +0100, Dominique Devienne wrote:
> > On Thu, Feb 29, 2024 at 10:03 AM Laurenz Albe
> wrote:
> > > You could use conditional indexes, but then you have to make sure that
> > > the optimizer knows it can use these
On Thu, 2024-02-29 at 10:55 +0100, Dominique Devienne wrote:
> On Thu, Feb 29, 2024 at 10:03 AM Laurenz Albe
> wrote:
>
> Honestly, I'm not sure why supporting the non-stored variant of generated
> columns is so controversial...
>
> > I am sure there are some use cases for "virtual" generated
On Thu, Feb 29, 2024 at 11:26 AM Peter Eisentraut
wrote:
> On 28.02.24 16:09, Dominique Devienne wrote:
> > Any chance PostgreSQL might gain actual virtual / non-stored generated
> > columns soon? Ever?
>
> I plan to work on this for PG18.
>
Thanks for the update, Peter and Alvaro. --DD
On 28.02.24 16:09, Dominique Devienne wrote:
We use generated columns extensively.
And we have foreign-keys attached to those generated columns.
The fact they are always Stored thus wastes space in our case.
Any chance PostgreSQL might gain actual virtual / non-stored generated
columns soon?
On 2024-Feb-29, Dominique Devienne wrote:
> Honestly, I'm not sure why supporting the non-stored variant of generated
> columns is so controversial...
I don't think there's anything controversial about virtual generated
columns, really ... it's just that it's tricky to implement and we don't
On Thu, Feb 29, 2024 at 10:03 AM Laurenz Albe
wrote:
> On Thu, 2024-02-29 at 08:55 +0100, Dominique Devienne wrote:
> Polymorphic Foreign Keys are nigh impossible to model well in SQL,
> and I doubt that non-stored generated columns will solve that.
>
It is modelled. It works. As I already
On Thu, 2024-02-29 at 08:55 +0100, Dominique Devienne wrote:
> On Wed, Feb 28, 2024 at 8:11 PM Tom Lane wrote:
> > Dominique Devienne writes:
> > > Views can have foreign-keys?
> >
> > Surely you'd put the FK on the underlying table.
>
> Again, the FKs are on the *generated* columns. So
>
>
On Wed, Feb 28, 2024 at 8:11 PM Tom Lane wrote:
> Dominique Devienne writes:
> > Views can have foreign-keys?
>
> Surely you'd put the FK on the underlying table.
>
Again, the FKs are on the *generated* columns. So
> > Generated view columns be indexed?
>
> [...[ it's hard to see much
On Wed, Feb 28, 2024 at 2:11 PM Tom Lane wrote:
> Dominique Devienne writes:
> > Views can have foreign-keys?
>
> Surely you'd put the FK on the underlying table.
>
> > Generated view columns be indexed?
>
> You want an index on a virtual column? Sure, just build an expression
> index (on the
Dominique Devienne writes:
> Views can have foreign-keys?
Surely you'd put the FK on the underlying table.
> Generated view columns be indexed?
You want an index on a virtual column? Sure, just build an expression
index (on the underlying table) that matches it.
I agree with Laurenz that
On Wed, Feb 28, 2024 at 5:59 PM Laurenz Albe
wrote:
> On Wed, 2024-02-28 at 16:09 +0100, Dominique Devienne wrote:
> > From https://www.postgresql.org/docs/16/ddl-generated-columns.html:
> > > PostgreSQL currently implements only stored generated columns
> >
> > We use generated columns
On Wed, 2024-02-28 at 16:09 +0100, Dominique Devienne wrote:
> From https://www.postgresql.org/docs/16/ddl-generated-columns.html:
> > PostgreSQL currently implements only stored generated columns
>
> We use generated columns extensively.
> And we have foreign-keys attached to those generated
13 matches
Mail list logo
