Jeff Janes writes:
> On Tue, May 31, 2022 at 4:04 PM Tim Kelly wrote:
>> I do not see evidence that the nested loop is trying to reduce overhead
>> by using the smaller set. It seems to want to scan on data first either
>> way.
> The planner probably doesn't know which one is smaller.
There
On Tue, May 31, 2022 at 4:04 PM Tim Kelly wrote:
>
> c_db=>select count(id) from metadata where author like '%Kelly%';
>
> count
> ---
>3558
> (1 row)
>
It would be interesting to see the explain of this. We know how many rows
it found, but not how many it thinks it will find.
> I
On Wed, 1 Jun 2022 at 08:04, Tim Kelly wrote:
> -> Seq Scan on data (cost=0.00..47132.93 rows=125 width=135)
> (actual time=0.542..182952.708 rows=1167810 loops=1)
> Filter: (data ~~ '%some text%'::text)
The problem is coming from the 125 row estimate in the above
On Wed, Jun 1, 2022 at 07:28:58PM +0300, Danny Shemesh wrote:
> Hey everyone,
>
> I'm working on improving gathered statistics on several large tables (2TB /
> 500M records);
> I've created extended stats on correlated columns, ran analyze, compared the
> pre and post explains, and it seems as
Hey everyone,
I'm working on improving gathered statistics on several large tables (2TB /
500M records);
I've created extended stats on correlated columns, ran analyze, compared
the pre and post explains, and it seems as though the extended statistics
are ignored -
the estimation doesn't change
Matthias Apitz writes:
> So far so good, but we do need this in ESQL/C. There the code looks as:
> EXEC SQL BEGIN DECLARE SECTION;
> charstmt[255];
> static char newCTID[80];
> EXEC SQL END DECLARE SECTION;
> memset(stmt, 0, sizeof(stmt));
>
While looking for a way to get the new CTID of an UPDATEd row, I came
accros this function currtid2() which works fine on SQL with a 14.1
server:
https://www.postgresql.org/message-id/Pine.BSO.4.44.0206031939050.21627-10%40kitten.greentechnologist.org
testdb=# SELECT ctid, * FROM dbctest
