Hi all,
I'm just having a doubt about the choice of the planner for a small
example table.
I've a table with a numeric column (integer), and I've created two
indexes on such column, one btree and one hash. The hash results much
larger as the btree, but what puzzles me is that executing an equality
On Fri, Nov 18, 2022 at 2:23 PM Tomas Vondra
wrote:
> That is, when comparing costs, we require the cost to be at least 1%,
> because we have a cheapest path, and we're checking if it's worth
> building another one (which is not free - we have to allocate stuff
> etc.). And if the difference is ti
On Fri, Nov 18, 2022 at 3:55 PM Tom Lane wrote:
> Even more to the point: if the total costs are fuzzily the same,
> then the next point of comparison will be the startup costs,
> which is where the hash index wins.
Thanks, it is clear now.
Luca
On Tue, Aug 13, 2019 at 10:23 AM Daulat Ram wrote:
> Initially did not have LongReadLen set, so I thought this was the cause. But,
> I have set LongReadLen, on the db handle, equal to 9000.
Apparently this is an oracle problem because it acceppted data longer
than its type, so my guess would
Hi all,
I'm running a virtual machine with FreeBSD 12.2, PostgreSQL 12.5 and
UFS as filesystem.
I was experimenting with fsync = off and pgbench, and I see no
particular difference in tps having fsync enabled or disabled.
Now, the same tiny test on a linux box provides a 10x tps, while on
FreeBSD i
On Mon, Feb 22, 2021 at 10:38 PM Thomas Munro wrote:
> Do you have WCE enabled? In that case, modern Linux file systems
> would do a synchronous SYNCHRONIZE CACHE for our WAL fdatasync(), but
> FreeBSD UFS wouldn't as far as I know. It does know how to do that
> (there's a BIO_FLUSH operation, a
On Tue, Feb 23, 2021 at 8:46 AM Luca Ferrari wrote:
> I'm using sata disks, not scsi. Assuming I'm not looking at the wrong
> parameter, I wil attach a scsi disk to do the same test and see if
> something changes.
I've tested the same version of PostgreSQL, same b
On Thu, Mar 11, 2021 at 3:29 PM Bruce Momjian wrote:
>
> You should really be running pg_test_fsync for this kind of testing.
>
Sorry Bruce, but it is not clear to me: pg_test_fsync compares
different fsync implementations, but not the fsync on/off setting of a
cluster.
Now, pg_test_fsync report
On Fri, Mar 12, 2021 at 10:34 AM Thomas Munro wrote:
> It looks like your system is performing very badly for some other
> reason, so that synchronous I/O waits are only a small proportion of
> the time, and thus fsync=off doesn't speed things up very much. I'd
> look into profiling the system to
Hi all,
I'm unable to find (apparently) a way to find out a possible value to
start with for effective_io_concurrency.
I suspect that benchmarking, e.g., using bonnie++ or sysbench and
testing with different values of concurrency could help to determine
the max number of concurrent request, (tps, l
On Thu, Apr 22, 2021 at 9:52 PM Bruce Momjian wrote:
>
> On Thu, Apr 22, 2021 at 09:45:15PM +0200, Luca Ferrari wrote:
> > Hi all,
> > I'm unable to find (apparently) a way to find out a possible value to
> > start with for effective_io_concurrency.
> > I sus
On Thu, Apr 22, 2021 at 10:15 PM Justin Pryzby wrote:
> Note that the interpretation of this GUC changed in v13.
> https://www.postgresql.org/docs/13/release-13.html
> |Change the way non-default effective_io_concurrency values affect
> concurrency (Thomas Munro)
> |Previously, this value was adj
On Wed, Jul 7, 2021 at 11:42 PM Merlin Moncure wrote:
> See thread, https://postgrespro.com/list/thread-id/2069516
>
> The setting only impacts certain scan operations, it's not a gamechanger.
Useful, thanks.
Luca
13 matches
Mail list logo
