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.
columns).
If that's a handful or so, it shouldn't be a big problem.
If you have hundred types (hundred referenced tables), you'd end up
with hundreds of indexes, and that already looks like a very bad idea
(both DML and query planning time will be affected).
Polymorphic Foreign Keys are nigh impossible to
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
> 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? Ever?
> >
>
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? Ever?
>
> For reference, both Oracle and SQLite have virtual / non-stored columns.
> And both
in our case.
Any chance PostgreSQL might gain actual virtual / non-stored generated
columns soon? Ever?
For reference, both Oracle and SQLite have virtual / non-stored columns.
And both support FKs and indexes on those too.
Would be great to have feature parity on this particular point, eventually.
14 matches
Mail list logo