On Sat, Jul 26, 2025 at 3:13 PM Igor Korot wrote:
>
> I didn't find the sorting for the field.
>
> Can you help?
The pg_index_column_has_property() can provide this information. E.g.,
select pg_index_column_has_property('my_index'::regclass, 2, 'desc');
On Sat, 2025-07-26 at 15:13 -0400, Igor Korot wrote:
> On Sat, Jul 26, 2025, 2:14 PM Christophe Pettus wrote:
> > > I want to know all individual things:
> > > - whether the index is unique.
> > > - what type of index it is
> > > - whether the field is ASC or DESC.
> > > - all other individual ara
Hi, Christopher,
On Sat, Jul 26, 2025, 2:14 PM Christophe Pettus wrote:
>
>
> > I want to know all individual things:
> > - whether the index is unique.
> > - what type of index it is
> > - whether the field is ASC or DESC.
> > - all other individual arams
>
> pg_index is the source for those.
> I want to know all individual things:
> - whether the index is unique.
> - what type of index it is
> - whether the field is ASC or DESC.
> - all other individual arams
pg_index is the source for those. The one exception is the access method for
the index, which is in pg_class.
Adrian,
On Sat, Jul 26, 2025 at 11:08 AM Adrian Klaver
wrote:
>
> On 7/26/25 08:00, Igor Korot wrote:
> > Hi, ALL,
> > Is there a better place to get the info about the index other than
> > https://www.postgresql.org/docs/current/view-pg-indexes.html
>
> What information do you need?
This is the
On Fri, Jul 25, 2025 at 7:13 PM Greg Sabino Mullane wrote:
>
> On Fri, Jul 25, 2025 at 9:57 AM Jon Zeppieri wrote:
>>
>> Thanks for the response, Nick. I'm curious why the situation you describe
>> wouldn't also lead to the write_lag and flush_lag also being
>> high. If the problem is simply kee
Adrian Klaver writes:
> On 7/26/25 08:00, Igor Korot wrote:
>> Is there a better place to get the info about the index other than
>> https://www.postgresql.org/docs/current/view-pg-indexes.html
> pg_class:
> https://www.postgresql.org/docs/current/catalog-pg-class.html
> and pg_attribute:
> https
On 7/26/25 08:00, Igor Korot wrote:
Hi, ALL,
Is there a better place to get the info about the index other than
https://www.postgresql.org/docs/current/view-pg-indexes.html
That guy has a full blown CREATE INDEX command and I will need to
parse it to get the info I need.
FYI,
pg_class:
https
On Sat, Jul 26, 2025, 08:00 Igor Korot wrote:
> Hi, ALL,
> Is there a better place to get the info about the index other than
> https://www.postgresql.org/docs/current/view-pg-indexes.html
>
> That guy has a full blown CREATE INDEX command and I will need to
> parse it to get the info I need.
>
On Sat, 26 Jul 2025, 17:00 Igor Korot, wrote:
> Hi, ALL,
> Is there a better place to get the info about the index other than
> https://www.postgresql.org/docs/current/view-pg-indexes.html
>
> That guy has a full blown CREATE INDEX command and I will need to
> parse it to get the info I need.
>
>
On 7/26/25 08:00, Igor Korot wrote:
Hi, ALL,
Is there a better place to get the info about the index other than
https://www.postgresql.org/docs/current/view-pg-indexes.html
What information do you need?
That guy has a full blown CREATE INDEX command and I will need to
parse it to get the inf
Hi, ALL,
Is there a better place to get the info about the index other than
https://www.postgresql.org/docs/current/view-pg-indexes.html
That guy has a full blown CREATE INDEX command and I will need to
parse it to get the info I need.
Thank you.
Also, Neon [0] and Aurora [1] pricing is so high that it seems to make most
use-cases impractical (well, if you want a managed offering...). Neon's top
public tier is not even what a single modern dedicated server (or virtual
machine) can provide. I would have thought decoupling compute and stor
Ah, by "shared storage" I mean that each node can acquire exclusivity, not that
they can both R/W to it at the same time.
> Some pretty well-known cases of storage / compute separation (Aurora, Neon)
> also share the storage between instances,
That model is cool, but I think it's more of a solu
Sorry, I was referring to this:
> But when PostgreSQL instances share storage rather than replicate:
> - Consistency seems maintained (same data)
> - Availability seems maintained (client can always promote an accessible
node)
> - Partitions between PostgreSQL nodes don't prevent the system from
What you describe doesn’t look like something very useful for the vast majority
of projects that needs a database. Why would you even want that if you can
avoid it?
If your “single node” can handle tens / hundreds of thousands requests per
second, still have very durable and highly available s
16 matches
Mail list logo
