On Mon, 25 Nov 2024, 06:08 Shaun Robinson,
wrote:
> Hi,
>
> I'm currently testing an application with Postgres 17.2 and am getting an
> error when creating a materialized view which works in version 16 and
> below. The sql works fine running as a query, but adding the
> create materialized view b
Instead of nickname you probably want tontet where password=`Arbol' .. or
am.i.missong something ?.
On Fri, 22 Nov 2024, 20:13 David G. Johnston,
wrote:
> On Fri, Nov 22, 2024 at 1:07 PM Arbol One wrote:
>
>> The below sql statement produces the right output
>> SELECT nickname, password FROM
i dont get why you think all memroy will be used.
When you say
shared_buffers = 16GB
effective_cache_size = 48GB
...then this is using only 16GB for shared buffers.
The effective _cache_size doesn't cause any memory to.be allocated. It's
just a hint to optomizer
On Wed, 20 Nov 2024, 11:16
getting a *custom*
plan as it's not a prepared statement.
On Sat, 9 Nov 2024, 03:46 ravi k, wrote:
> Sorry, it was typo. Bind variable is bigint only.
>
> Thanks
>
> On Fri, 8 Nov, 2024, 7:09 pm David Mullineux, wrote:
>
>> Just spotted a potential problem. T
may face latency issues and lower environment this issue cannot
> be reproduced,( this is happening out of Million one case)
>
> This looks puzzle to us, just in case anyone experianced pls share your
> experience.
>
> Regards,
> Ravi
>
> On Thu, 7 Nov, 2024, 3:41 am David
It might be worth eliminating the use of cached plans here. Is your app
using prepared statements at all?
Point is that if the optimizer sees the same prepared query , 5 times, the
it locks the plan that it found at that time. This is a good trade off as
it avoids costly planning-time for repetitiv
Are you able to cluster the table ? The idea is that rows ordered in the
same way as the index might reduce it's size ?
On Wed, 30 Oct 2024, 16:29 Don Seiler, wrote:
> On Wed, Oct 30, 2024 at 11:23 AM Peter Geoghegan wrote:
>
>>
>> If a substantial amount of the index was written by CREATE IND
Hi,
Its usually helpful to give some details on what 'slow' means and then
define what 'fast enough ' means. Just so we know when to stop optimizing.
You should also help by giving the DDL of those.tables and any indexes they
have etc..
The plan shows me that there are expensive seq scans on 2 tabl
I would usually try to avoid such long IN causes. Why not try this ..
Create a temp table of 1 column. Bulk insert all your IDs into that table.
Then change your query to join to the temp table? This also has the
advantage of working for 1000s of values.
On Fri, 13 Sept 2024, 16:35 Wong, Kam
Yes, PostgreSQL.
Why not just do this via SQL join ?
On Tue, 3 Sept 2024, 17:34 arun chirappurath, wrote:
> Hi All,
>
> Do we have any open-source utility to compare two table data not structure
> and then provide some sort of reports?
>
> Row by row comparison
>
> Thanks,
> Arun
>
10 matches
Mail list logo
