Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tz7TX-00FKmQ-5J for pgsql-general@arkaria.postgresql.org; Mon, 31 Mar 2025 05:14:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tz7TV-000Qxf-KC for pgsql-general@arkaria.postgresql.org; Mon, 31 Mar 2025 05:14:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tz7QI-000Lh5-Jo for pgsql-general@lists.postgresql.org; Mon, 31 Mar 2025 05:10:58 +0000 Received: from mail-oo1-xc2d.google.com ([2607:f8b0:4864:20::c2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tz7QG-0024lL-39 for pgsql-general@lists.postgresql.org; Mon, 31 Mar 2025 05:10:57 +0000 Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-5fc6cd89f85so2307246eaf.1 for ; Sun, 30 Mar 2025 22:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743397856; x=1744002656; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QR17irMLIXFPx7vsbJSQPKY3Q3yhXQiO+BS6qG/a2p0=; b=DzpMkjzwpgqM8i7B1Oiluy2q4ObVqzQ/RVhsOcoZRQXF867AGTtJc826NShH8Mwl3F 3TkMUDcJAY8w1YIrCKoxhZyDvJ+UXLAbrDR/wJlbcmtlSNS/ggQ9agR6WsRod7Q9c8MQ j/jnoNA31hTAEykESdfy1s3XZwj6ta9/CwUziueaoljnbAVOnB6ec7yBJJxOiDrIrPHw 28CV79eCg01EwZA8R03XWifTe9MsjUEqNaF5+gGwm63dSoLYKRoI/+sPwsSNjtL2TWzN QXq8eaWYeL3Vix5pdlE1YR22bIXaYGTBCmUFMqbpQwFYUfTkunblMhxyRI6iXDzWF34g ckVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743397856; x=1744002656; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QR17irMLIXFPx7vsbJSQPKY3Q3yhXQiO+BS6qG/a2p0=; b=jN4/UR1tymXbE8VtxBLl6bVRB9JclPb2nQDMhsakYmtCcBjKPNBath/kMfLZj1Ff9O 7NCD6Ae/riY7Lz5dcios99xkO+wWUO/o1+yvoTK2345L+UEY5Q/FqwHykKzdh9zR4zOb 2dBJxF6ZgoQDW4snHRD67C89sqvmz2N38NGkD43FzCA+q+svbe9lsVpA02YfZHR88cLU +2Yemvp/26mnl0QkP9xQoody8tMqpSAUQtA7N4v3jgo08sEP4LsHYM/klgo1Z81aZsv7 4Ai4tH41WXC+Jer8iE3CXTNJ9vl7B2+a5hit1Pde4FDeYOyykOMBPmMbzB9Gbg6d4BBZ hDsQ== X-Gm-Message-State: AOJu0Yzm3w51tJp0+OMmlAg9NAAida3g1Zw3vOYR7XRTGq4CPY1g6lsq MKxA41Uc+MXh/cVp16NbPry2LZYbUglVXLUpN+GF6SMuigWT8NPLkTQSXBqmzIH2uko8kFLkGeE 2NSVspZQIATLzVwfBUP+B6Hfqz9I= X-Gm-Gg: ASbGncuC8aAffmRTLhD48MR2twQ8usvQN5FeUce8T9SlJGDQDASHMhLD0VzSn5urGlW fBx+b4th2+ck4XytcbNAYsnS1/vh5HHSAPgkmH/ifhG8/LrQ0RWlIrUhR8atqswHoVSaKpF7n6/ KM4whGySzqP0LNJseK+vlWK2FB X-Google-Smtp-Source: AGHT+IHwP0RDrN/MyJtBJ0z2K1hPBzOH7Pbcr7r9B5I7BNLnt1vsxBF6Kc3Beo00sxHPvMqauaa8ILS0eVmEziU0L38= X-Received: by 2002:a05:6870:71c1:b0:2b8:e4b9:47a3 with SMTP id 586e51a60fabf-2cbcf564c0bmr3747916fac.22.1743397856344; Sun, 30 Mar 2025 22:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:53c2:0:b0:589:13f9:e937 with HTTP; Sun, 30 Mar 2025 22:10:54 -0700 (PDT) In-Reply-To: References: From: "David G. Johnston" Date: Sun, 30 Mar 2025 22:10:54 -0700 X-Gm-Features: AQ5f1JqPOqOnMtcVrQt7YDaTeniFF5pA0dD3ssmtDegS0CVSKPzswnwtk00j0Fc Message-ID: Subject: Re: SQL Server's WITH (NOLOCK) equivalent in PostgreSQL? To: =?UTF-8?B?7J207ZiE7KeE?= Cc: "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000ee02f406319c71fa" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ee02f406319c71fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, March 30, 2025, =EC=9D=B4=ED=98=84=EC=A7=84 wrote: > > Since PostgreSQL uses MVCC, I'm wondering what the best practice is for > non-blocking reads, > and whether there's an equivalent to dirty reads or READ UNCOMMITTED. > https://www.postgresql.org/docs/current/transaction-iso.html We are unable to implement read uncommitted because of our choice to implement MVCC. There is no equivalent because the fundamental operating decisions doesn=E2=80=99t allow for one. If you don=E2=80=99t pre-suppose the solution of dirty reads and instead su= pply a use case and desired constraints maybe an alternative approach for that use case could be suggested. David J. --000000000000ee02f406319c71fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, March 30, 2025, =EC=9D=B4=ED=98=84=EC=A7=84 <jemie9812@gmail.com> wrote:

Since PostgreS= QL uses MVCC, I'm wondering what the best practice is for non-blocking = reads,
and whether there's an equivalent to dirty reads or READ UNC= OMMITTED.


We are una= ble to implement read uncommitted because of our choice to implement MVCC.= =C2=A0 There is no equivalent because the fundamental operating decisions d= oesn=E2=80=99t allow for one.

If you don=E2=80=99t= pre-suppose the solution of dirty reads and instead supply a use case and = desired constraints maybe an alternative approach for that use case could b= e suggested.

David J.

--000000000000ee02f406319c71fa--