Thanks! This is very helpful.
On Wed, Oct 29, 2025 at 8:01 PM David Rowley wrote:
> On Thu, 30 Oct 2025 at 07:29, Jacob Jackson
> wrote:
> > Hello. I was looking at some query plans recently and noticed something
> that didn't make sense. I have a query that joins a table of questions with
> re
The performance/cost difference persists with identical keys. Why would the
planner for the memorized query use different statistics/calculations in
the first place?
On Wed, Oct 29, 2025 at 5:48 PM Ron Johnson wrote:
> You're running slightly different queries:
> enable_memoize=on: Index Cond: (
On Thu, 30 Oct 2025 at 07:29, Jacob Jackson wrote:
> Hello. I was looking at some query plans recently and noticed something that
> didn't make sense. I have a query that joins a table of questions with
> results for each question (using a table with a composite primary key of
> question id and
You're running slightly different queries:
enable_memoize=on: Index Cond: ("user" = '0'::bigint)
enable_memoize=off: Index Cond: ("user" = '3477145805513'::bigint)
All buffer counts look to be the same on both, and 514 is just 1.5% smaller
than 522. That looks like statistical noise to me.
On W
I was curious to see whether there was any reason I wasn't seeing for
Postgres to decide the memoized version was lower cost and try to memoize
these operations.
On Wed, Oct 29, 2025 at 3:20 PM Ron Johnson wrote:
> What's the actual problem? Does enable_memoize=on return incorrect
> results?
>
What's the actual problem? Does enable_memoize=on return incorrect results?
Because a 45 microsecond (yes, 45 microseconds: 0.138 milliseconds = 138
microseconds; same for the others) slowdown isn't something I'd get too
worked up about.
On Wed, Oct 29, 2025 at 2:29 PM Jacob Jackson
wrote:
> H
Hello. I was looking at some query plans recently and noticed something
that didn't make sense. I have a query that joins a table of questions with
results for each question (using a table with a composite primary key of
question id and a user id), filtered by user id. The question IDs and the
comb
On 10/29/25 06:40, Colin 't Hart wrote:
As expected the dump contains:
CREATE TABLE . (
,
id bigint NOT NULL
);
--
-- Name: ; Type: SEQUENCE; Schema: ; Owner:
--
ALTER TABLE . ALTER COLUMN id ADD GENERATED ALWAYS
AS IDENTITY (
SEQUENCE NAME .
START WITH 1
INCREMENT BY 1
On 29.10.25 12:27, Colin 't Hart wrote:
One of my clients has a database in which a single identity column
(called "id" in that table) has two sequences associated with it(!)
Both sequences display
Sequence for identity column: ..id
when described with \d in psql.
Inserting fails with "ERROR
I'd have expected the CREATE SEQUENCE and ALTER TABLE to be separate that
can go in the post-data section, and be there even in schema-only dumps
because it was easier for whoever added sections to pg_dump. After all,
what really matters is the destination, not the journey.
On Wed, Oct 29, 2025 a
On 10/29/25 07:47, kurt thepw.com wrote:
<
< CREATE TABLE . (
< ,
< id bigint NOT NULL
< );
<
I've never seen a plaintext pg_dump output where the sequence
associated with a column in a table was not mentioned in s "DEFAULT
nextval(..." modifier in that column's line of the CREATE TABLE
s
<
< CREATE TABLE . (
< ,
< id bigint NOT NULL
< );
<
I've never seen a plaintext pg_dump output where the sequence associated with
a column in a table was not mentioned in s "DEFAULT nextval(..." modifier in
that column's line of the CREATE TABLE statement, ex:
<
< CREATE TABLE . (
As expected the dump contains:
CREATE TABLE . (
,
id bigint NOT NULL
);
--
-- Name: ; Type: SEQUENCE; Schema: ; Owner:
--
ALTER TABLE . ALTER COLUMN id ADD GENERATED ALWAYS
AS IDENTITY (
SEQUENCE NAME .
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1
);
On Wednesday, October 29, 2025, Dominique Devienne
wrote:
> On Wed, Oct 29, 2025 at 2:17 PM kurt thepw.com wrote:
> >If this is a development database, perhaps you can do a schema-only
> pg_dump of it in plain text format, manually edit out the offending second
> sequence from the resulting
On Wed, Oct 29, 2025 at 2:17 PM kurt thepw.com wrote:
>If this is a development database, perhaps you can do a schema-only
> pg_dump of it in plain text format, manually edit out the offending second
> sequence from the resulting SQL file, and restore it into a new database.
I'm surprised
If this is a development database, perhaps you can do a schema-only
pg_dump of it in plain text format, manually edit out the offending second
sequence from the resulting SQL file, and restore it into a new database.
Yours,
Kurt Reimer
From: Colin 't Hart
Again as I wrote above, drop identity complains about more than one sequence.
I have no idea how this customer arrived at this situation or if it
affects other environments (this is actually a dev database that we're
trying to upgrade as the first step in an upgrade project).
I suspect the dump w
On Wed, Oct 29, 2025 at 01:04:48PM +0100, Colin 't Hart wrote:
> Thanks. But as I wrote above, trying to alter either of the two
> sequences and specifying "owned by none" results in the error.
Sorry, missed that.
Can you please provide pg_dump output from this db, just schema, just
this one tabl
Thanks. But as I wrote above, trying to alter either of the two
sequences and specifying "owned by none" results in the error.
/Colin
On Wed, 29 Oct 2025 at 13:02, hubert depesz lubaczewski
wrote:
>
> On Wed, Oct 29, 2025 at 12:27:44PM +0100, Colin 't Hart wrote:
> > One of my clients has a data
On Wed, Oct 29, 2025 at 12:27:44PM +0100, Colin 't Hart wrote:
> One of my clients has a database in which a single identity column
> (called "id" in that table) has two sequences associated with it(!)
> Both sequences display
> Sequence for identity column: ..id
> when described with \d in psql.
>
Hi,
One of my clients has a database in which a single identity column
(called "id" in that table) has two sequences associated with it(!)
Both sequences display
Sequence for identity column: ..id
when described with \d in psql.
Inserting fails with "ERROR: more than one owned sequence found
21 matches
Mail list logo
