Am Sun, Feb 11, 2024 at 12:53:10PM +0530 schrieb veem v:
> >> Pagination is already a hard problem, and does not even make sense when
> > combined with "a continuous stream of inserts". What should the user see
> > when they click on page 2?
> >
>
> When the user clicks to the second page , it wil
On Sun, 2024-02-11 at 13:25 +0530, veem v wrote:
> On Sun, 2024-02-11 at 01:25 +0100, Peter J. Holzer wrote:
> > On 2024-02-06 11:25:05 +0530, veem v wrote:
> > > With respect to the storage part:- In Oracle database we were supposed to
> > > keep
> > > the frequently accessed column first and les
On 2024-02-11 13:25:10 +0530, veem v wrote:
> On Sun, 11 Feb 2024 at 05:55, Peter J. Holzer wrote:
> Yes. Numbers in Oracle are variable length, so most Oracle tables
> wouldn't contain many fixed length columns. In PostgreSQL must numeric
> types are fixed length, so you'll have quite
Hi Marc,
Nested partitioning still allows for simple data deletion by dropping the
table that falls in that date range.
Probably thinking of partitioning by multicolomn rules which is very
complex to set up
On Fri, Feb 9, 2024, 10:29 AM Marc Millas wrote:
>
>
>
> On Thu, Feb 8, 2024 at 10:25
On Sun, 11 Feb 2024 at 19:02, Peter J. Holzer wrote:
> > Similarly for Number/Numeric data type.
>
> Number in Oracle and numeric in PostgreSQL are variable length types.
> But in PostgreSQL you also have a lot of fixed length numeric types
> (from boolean to bigint as well as float4 and float8)
On Sunday, February 11, 2024, veem v wrote:
>
> On Sun, 11 Feb 2024 at 19:02, Peter J. Holzer wrote:
>
>> > Similarly for Number/Numeric data type.
>>
>> Number in Oracle and numeric in PostgreSQL are variable length types.
>> But in PostgreSQL you also have a lot of fixed length numeric types
>
On Sun, Feb 11, 2024 at 11:54 AM veem v wrote:
[snip]
> When you said *"you would normally prefer those over numeric " *I was
> thinking the opposite. As you mentioned integer is a fixed length data type
> and will occupy 4 bytes whether you store 15 or .But in case of
> variable length t
Hello,
I'm new to PostgreSQL. I'm trying to migrate an app from SqlServer to
Postgres (it's written in C# and uses Npgsql)
I've tried with Postgres 16.1 and 16.2 on Windows Server 2019.
This app used SqlServer's Bulk Insert to import some tables (about 50
tables) from another database, I rep
On 2/11/24 13:37, ste...@gmail.com wrote:
Hello,
I’m new to PostgreSQL. I’m trying to migrate an app from SqlServer to
Postgres (it’s written in C# and uses Npgsql)
I’ve tried with Postgres 16.1 and 16.2 on Windows Server 2019.
This app used SqlServer’s Bulk Insert to import some tables (abo
On 2024-02-11 22:23:58 +0530, veem v wrote:
> On Sun, 11 Feb 2024 at 19:02, Peter J. Holzer wrote:
>
> > Similarly for Number/Numeric data type.
>
> Number in Oracle and numeric in PostgreSQL are variable length types.
> But in PostgreSQL you also have a lot of fixed length numeric t
On 2024-02-11 12:08:47 -0500, Ron Johnson wrote:
> On Sun, Feb 11, 2024 at 11:54 AM veem v wrote:
> When you said "you would normally prefer those over numeric " I was
> thinking the opposite. As you mentioned integer is a fixed length data
> type
> and will occupy 4 bytes whether you
On Sun, Feb 11, 2024 at 4:41 PM Adrian Klaver
wrote:
> On 2/11/24 13:37, ste...@gmail.com wrote:
>
[snip]
> >
> > The same query, executed from pgAdmin, returns the result in less than a
> > second (even if it’s executed while the query from my app is running).
> >
> > (actually the result are 0
Thanks, Adrian, for the suggestion, but same problem.
I've just tried to execute "ANALYZE" (on the whole database) after the import
of all the tables (with COPY) and before the other queries, but the query
always hangs (I hope this was the way you suggested).
Stefano
> -Original Message---
Since the query works in PgAdmin, but not in npgsql, the problem has to be
somewhere in Npgsql.
https://www.npgsql.org/doc/diagnostics/overview.html
Maybe increasing the log level will lead to a solution.
On Sun, Feb 11, 2024 at 6:13 PM wrote:
> Thanks, Adrian, for the suggestion, but same pro
Ron Johnson writes:
> Since the query works in PgAdmin, but not in npgsql, the problem has to be
> somewhere in Npgsql.
I'm wondering if npgsql is executing the query as a cursor and that
is causing the planner to make a poor choice of plan. There is a
bias towards fast-start plans if you use a
Thank you .
On Mon, 12 Feb 2024 at 03:52, Peter J. Holzer wrote:
> On 2024-02-11 12:08:47 -0500, Ron Johnson wrote:
> > On Sun, Feb 11, 2024 at 11:54 AM veem v wrote:
> > When you said "you would normally prefer those over numeric " I was
> > thinking the opposite. As you mentioned inte
16 matches
Mail list logo