Hi Alvaro,
On Thu, May 4, 2023 at 19:44 Alvaro Herrera wrote:
> On 2023-May-02, Alvaro Herrera wrote:
>
> > We have an open item about this, and I see no reason not to do it. I
> > checked, and putting things back is just a matter of reverting
> > 589bb816499e and ec386948948, cleaning up some
On 2023-May-02, Alvaro Herrera wrote:
> We have an open item about this, and I see no reason not to do it. I
> checked, and putting things back is just a matter of reverting
> 589bb816499e and ec386948948, cleaning up some trivial pgindent-induced
> conflicts, and bumping catversion once more. W
Hi Amit,
On 2023-Mar-30, Alvaro Herrera wrote:
> On 2023-Mar-29, Amit Langote wrote:
> > Though, I wonder if we need to keep ec386948948 that introduced the
> > notion of part_prune_index around if the project that needed it [1]
> > has moved on to an entirely different approach altogether, one
On 2023-Mar-29, Amit Langote wrote:
> On Wed, Mar 29, 2023 at 3:39 AM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > So I'm back home and found a couple more weird errors in the log:
> >
> > > ERROR: mismatching PartitionPruneInfo found at part_prune_index 0
> > > DETALLE: plan node relids (
On Wed, Mar 29, 2023 at 3:39 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > So I'm back home and found a couple more weird errors in the log:
>
> > ERROR: mismatching PartitionPruneInfo found at part_prune_index 0
> > DETALLE: plan node relids (b 1), pruneinfo relids (b 36)
>
> This one reprod
Alvaro Herrera writes:
> So I'm back home and found a couple more weird errors in the log:
> ERROR: mismatching PartitionPruneInfo found at part_prune_index 0
> DETALLE: plan node relids (b 1), pruneinfo relids (b 36)
This one reproduces for me.
> select
> pg_catalog.pg_stat_get_buf_f
So I'm back home and found a couple more weird errors in the log:
MERGE INTO public.idxpart2 as target_0
USING (select 1
from
public.xmltest2 as ref_0
inner join public.prt1_l_p1 as sample_0
inner join fkpart4.droppk as ref
I wrote:
> The planner is reducing the scan of target_parted to
> a dummy scan, as is reasonable, but it forgets to
> provide ctid as an output from that scan; then the
> parent join node is unhappy because it does have
> a ctid output. So it looks like the problem is some
> shortcut we take while
I wrote:
> I reduced this down to
> MERGE INTO public.target_parted as target_0
> USING public.itest1 as ref_0
> ON target_0.b = ref_0.a
> WHEN NOT MATCHED
>THEN INSERT VALUES (42, 13);
> The critical moving part seems to just be that the MERGE target
> is a partitioned table
Alvaro Herrera writes:
> I have to run now so can't dissect it, but while running sqlsmith on the
> SQL/JSON patch after Justin's report, I got $SUBJECT in this query:
I reduced this down to
MERGE INTO public.target_parted as target_0
USING public.itest1 as ref_0
ON target_0.b = ref_0.a
Alvaro Herrera writes:
> I have to run now so can't dissect it, but while running sqlsmith on the
> SQL/JSON patch after Justin's report, I got $SUBJECT in this query:
Reproduces in HEAD and v15 too (once you replace pg_catalog.system_user
with some function that exists in v15). So it's not the
I have to run now so can't dissect it, but while running sqlsmith on the
SQL/JSON patch after Justin's report, I got $SUBJECT in this query:
MERGE INTO public.target_parted as target_0
USING (select
subq_0.c5 as c0,
subq_0.c0 as c1,
ref_0.a as c2,
s
I wrote:
> That ... is pretty quirky already. How did it prefer a scan with cost
> 19.32 over one with cost 9.39? Seems like we've got a bug here somewhere.
> The change in estimated rowcount is rather broken, too.
Ah, false alarm. I can reproduce your results if I stick an ANALYZE
between the
David Rowley writes:
> On Wed, 8 Jun 2022 at 07:55, Tom Lane wrote:
>> I wonder if there is some quirk in gist cost estimation that makes it
>> improperly claim to be cheaper than btree scans.
> I installed PostGIS 3.1.1 and mocked this up with the attached.
> Looking at the plans, I see:
> #
On Wed, 8 Jun 2022 at 08:31, David Rowley wrote:
> So it does appear that the location index is being chosen, at least
> with the data that I inserted. Those gist indexes are costing quite a
> bit cheaper than the cheapest btree index.
This seems just to be because the gist indexes are smaller, w
On Wed, 8 Jun 2022 at 07:55, Tom Lane wrote:
>
> David Rowley writes:
> > On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
> > wrote:
> >> Here is the detail of the table (I have anonymized it on SO, this is its
> >> real name):
> >> "logistic_site_location_54ae0166_id" gist (location
David Rowley writes:
> On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
> wrote:
>> Here is the detail of the table (I have anonymized it on SO, this is its
>> real name):
>> "logistic_site_location_54ae0166_id" gist (location)
> I imagine this is due to the planner choosing an index-o
On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
wrote:
> Here is the detail of the table (I have anonymized it on SO, this is its real
> name):
> "logistic_site_location_54ae0166_id" gist (location)
I imagine this is due to the planner choosing an index-only scan on
the above ind
Dear David,
Thank you for taking time on this issue.
Here is the detail of the table (I have anonymized it on SO, this is its real
name):
\d logistic_site
Table « public.logistic_site »
Colonne | Type | Collationnement | NULL-ab
On Mon, 6 Jun 2022 at 21:34, Jean Landercy - BEEODIVERSITY
wrote:
> SELECT COUNT(*) FROM items;
> -- ERROR: variable not found in subplan target list
> -- SQL state: XX000
Can you share some more details about what "items" is. psql's "\d
items" output would be
On Mon, Jun 06, 2022 at 04:50:55PM +, Jean Landercy - BEEODIVERSITY wrote:
> Dear Justin,
>
> Thank you for your quick reply.
> Unfortunately, the server having this issue is an Azure Flexible Server.
> Upgrades are managed by Azure, I will have to wait until they release the
> version 13.7.
Dear Justin,
Thank you for your quick reply.
Unfortunately, the server having this issue is an Azure Flexible Server.
Upgrades are managed by Azure, I will have to wait until they release the
version 13.7.
Is there a procedure to replicate the database and preserve the bug.
My attempts with pg_d
On Mon, Jun 06, 2022 at 09:34:24AM +, Jean Landercy - BEEODIVERSITY wrote:
> Faulty setup is about:
>
> SELECT version();
>
> -- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
Please check if the problem occurs in v13.7
https://www.pos
list
-- SQL state: XX000
Message and behaviour seem related to the Query Planner:
EXPLAIN SELECT COUNT(*) FROM item;
-- ERROR: variable not found in subplan target list
-- SQL state: XX000
Looks like a column name could not be found (see
https://github.com/postgres/postgres/blob
24 matches
Mail list logo
