On Saturday, May 15, 2021, Venkata B Nagothi wrote:
>
>
> *ERROR: column c.relhaspkey does not exist at character 33*
>
> Below is the query generating the error :
>
> STATEMENT: SELECT c.relname AS table_name, c.relhaspkey AS
> has_primary_key FROM pg_catalog.pg_class c, pg_catalog.pg_namespac
On Mon, May 10, 2021 at 9:26 AM Venkata B Nagothi wrote:
>
>
> On Sat, 8 May 2021 at 1:47 pm, Laurenz Albe
> wrote:
>
>> On Sat, 2021-05-08 at 13:37 +1000, Venkata B Nagothi wrote:
>> > We are thinking to upgrade to PG 11 instead so that we can avoid doing
>> ALTER TABLE.. SET WITHOUT OIDs.
>> >
Luca Ferrari writes:
> On Sat, May 15, 2021 at 4:40 PM David Rowley wrote:
>> The answer is fairly simple, the planner just never considers using
>> the primary key index as there are no possible cases where it would be
>> useful.
> Does this mean that any UNIQUE constraint on the table is subje
On Sat, May 15, 2021 at 4:40 PM David Rowley wrote:
>
> The answer is fairly simple, the planner just never considers using
> the primary key index as there are no possible cases where it would be
> useful.
Does this mean that any UNIQUE constraint on the table is subject to
the same consideratio
On Sun, 16 May 2021, 12:15 am Luca Ferrari, wrote:
> So far so good, but if I disable seqscan I would expect the planner to
> choose the primary key index, because that "should be" the preferred
> way to access the table.
> On the other hand, the planner enables JIT machinery and executes
> again
Hi all,
doing a little and trivial experiment, I decided to populate a table
with a primary key (and thus an automatically generated btree index):
testdb=# create table foo( pk serial primary key, i int );
CREATE TABLE
testdb=# insert into foo( i ) select v from generate_series( 1, 100 ) v;
IN
