[HACKERS] dead or outdated URLs found in win32.h

Hi All, The following URLs present in src/include/port/win32.h to share the information on dllimport or dllexport (used in windows) seems to be either dead/obsolete and i think, they need to be updated. http://support.microsoft.com/kb/132044 -- dead

Re: [HACKERS] [PATCH] A hook for session start

2017-10-07 6:49 GMT+02:00 Nico Williams : > On Sat, Oct 07, 2017 at 05:44:00AM +0200, Pavel Stehule wrote: > > 2017-10-06 21:36 GMT+02:00 Nico Williams : > > > But the nice thing about them is that you need only create them once, > so > > > leave them

Re: [HACKERS] [PATCH] A hook for session start

On Sat, Oct 07, 2017 at 05:44:00AM +0200, Pavel Stehule wrote: > 2017-10-06 21:36 GMT+02:00 Nico Williams : > > But the nice thing about them is that you need only create them once, so > > leave them in the catalog. Stats about them should not be gathered nor > > stored,

Re: [HACKERS] [PATCH] A hook for session start

2017-10-06 21:36 GMT+02:00 Nico Williams : > On Fri, Oct 06, 2017 at 08:51:53PM +0200, Pavel Stehule wrote: > > 2017-10-06 20:39 GMT+02:00 Nico Williams : > > > On Fri, Oct 06, 2017 at 06:37:57PM +0200, Pavel Stehule wrote: > > > > When we talked

Re: [HACKERS] Discussion on missing optimizations

On 2017-10-06 22:19:54 -0400, Tom Lane wrote: > The impression I have in a quick scan is that probably hardly any of these > are cases that any of the DB designers think are important in > themselves. > In the end, what the article fails to consider is that all of these are > tradeoffs, not

Re: [HACKERS] Discussion on missing optimizations

Andres Freund writes: > On 2017-10-06 21:33:16 -0400, Adam Brusselback wrote: >> The article in question is here: >> https://blog.jooq.org/2017/09/28/10-cool-sql-optimisations-that-do-not-depend-on-the-cost-model/ > That's interesting. The impression I have in a quick scan

Re: [HACKERS] Discussion on missing optimizations

Hi, On 2017-10-06 21:33:16 -0400, Adam Brusselback wrote: > Hopefully it's alright for me to post this here, please let me know if not. > I ran across an article on blog.jooq.org comparing all the major RDBMS' > with their ability to optimize away unnecessary work with queries which are > less

[HACKERS] Discussion on missing optimizations

Hopefully it's alright for me to post this here, please let me know if not. I ran across an article on blog.jooq.org comparing all the major RDBMS' with their ability to optimize away unnecessary work with queries which are less than optimal, and saw some discussion on hackernews and reddit, but

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 2:09 PM, Wong, Yi Wen wrote: > Yesterday, I've been spending time with pg_visibility on the pages when I > reproduce the issue in 9.6. > None of the all-frozen or all-visible bits are necessarily set in problematic > pages. Since this happened

Re: [HACKERS] Re: protocol version negotiation (Re: Libpq PGRES_COPY_BOTH - version compatibility)

Hi Tom and Robert, I added a mechanism to fall back to v3.0 if the BE fails to start when FE initiates a connection with v3.1 (with optional startup parameters). This completely eliminates the need to backpatch older servers, ie newer FE can connect to older BE. Please let me know what you

Re: [HACKERS] separate serial_schedule useful?

Peter Eisentraut writes: > I noticed that the test "hash_func" was listed in parallel_schedule but > not in serial_schedule. I have seen that a few times recently where a > patch proposes to add a new test file but forgets to add it to the > serial_schedule.

[HACKERS] separate serial_schedule useful?

I noticed that the test "hash_func" was listed in parallel_schedule but not in serial_schedule. I have seen that a few times recently where a patch proposes to add a new test file but forgets to add it to the serial_schedule. I wonder whether it's still useful to keep two separate test lists. I

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Oct 06, 2017 at 08:51:53PM +0200, Pavel Stehule wrote: > 2017-10-06 20:39 GMT+02:00 Nico Williams : > > On Fri, Oct 06, 2017 at 06:37:57PM +0200, Pavel Stehule wrote: > > > When we talked about this topic, there are two issues: > > > > > > a) probably not too hard

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Oct 6, 2017 at 3:07 PM, Ashutosh Bapat wrote: > On Fri, Oct 6, 2017 at 8:45 PM, Robert Haas wrote: >> I think this is very good work and I'm excited about the feature. Now >> I'll wait to see whether the buildfarm, or Tom, yell at

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 11:34 AM, Peter Geoghegan wrote: >> I don't know if it's really the freeze map at fault or something else. > > Ideally, it would be possible to effectively disable the new freeze > map stuff in a minimal way, for testing purposes. Perhaps the authors > of that

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Fri, Oct 6, 2017 at 1:22 PM, Paul A Jungwirth wrote: > On Fri, Jul 22, 2016 at 4:15 AM, Anton Dignös wrote: >> We would like to contribute to PostgreSQL a solution that supports the query >> processing of "at each time point". The basic

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Oct 6, 2017 at 8:45 PM, Robert Haas wrote: > > I think this is very good work and I'm excited about the feature. Now > I'll wait to see whether the buildfarm, or Tom, yell at me for > whatever problems this may still have... > Buildfarm animal prion turned red.

Re: [HACKERS] [PATCH] A hook for session start

2017-10-06 20:39 GMT+02:00 Nico Williams : > On Fri, Oct 06, 2017 at 06:37:57PM +0200, Pavel Stehule wrote: > > 2017-10-06 6:48 GMT+02:00 Nico Williams : > > > On Fri, Oct 06, 2017 at 04:52:09AM +0200, Pavel Stehule wrote: > > > > Current TEMP tables,

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Oct 06, 2017 at 06:37:57PM +0200, Pavel Stehule wrote: > 2017-10-06 6:48 GMT+02:00 Nico Williams : > > On Fri, Oct 06, 2017 at 04:52:09AM +0200, Pavel Stehule wrote: > > > Current TEMP tables, if you do it for any session has pretty significant > > > overhead - with

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 10:49 AM, Alvaro Herrera wrote: > I can tell that, in 9.6, REINDEX still reports the error we saw in > earlier releases, after some of the runs of my reproducer scripts. I'm > unable to reproduce it anymore in 9.3 to 9.5. I can't see the one Dan >

Re: [HACKERS] Proposal: Local indexes for partitioned table

Hi! On 06.10.2017 19:37, Alvaro Herrera wrote: As you propose, IMO this new feature would use the standard index creation syntax: CREATE [UNIQUE] INDEX someindex ON parted_table (a, b); This command currently throws an error. We'd have it do two things: 1. create catalog rows in

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 7:59 AM, Alvaro Herrera wrote: > By the way, I still wonder if there's any way for a new tuple to get > inserted in the place where a HOT redirect would be pointing to, and > have it be marked as Frozen, where the old redirect contains a >

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Peter Geoghegan wrote: > On Fri, Oct 6, 2017 at 6:18 AM, Alvaro Herrera > wrote: > > Wood, Dan wrote: > >> Yes, I’ve been testing 9.6. I’ll try Alvaro’s patch today. > >> > >> I would prefer to focus on either latest 9X or 11dev. > > > > I tested my patch on 9.4 and 9.5

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Fri, Jul 22, 2016 at 4:15 AM, Anton Dignös wrote: > We would like to contribute to PostgreSQL a solution that supports the query > processing of "at each time point". The basic idea is to offer two new > operators, NORMALIZE and ALIGN, whose purpose is to adjust (or

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 6:18 AM, Alvaro Herrera wrote: > Wood, Dan wrote: >> Yes, I’ve been testing 9.6. I’ll try Alvaro’s patch today. >> >> I would prefer to focus on either latest 9X or 11dev. > > I tested my patch on 9.4 and 9.5 today and it seems to close the problem

Re: [HACKERS] [PATCH] A hook for session start

2017-10-06 6:48 GMT+02:00 Nico Williams : > On Fri, Oct 06, 2017 at 04:52:09AM +0200, Pavel Stehule wrote: > > 2017-10-05 22:31 GMT+02:00 Nico Williams : > > > On Tue, Aug 01, 2017 at 03:36:23PM -0400, Peter Eisentraut wrote: > > > > On 7/21/17 13:14,

Re: [HACKERS] Proposal: Local indexes for partitioned table

Hello I've been thinking about this issue too. I think your patch is not ambitious enough. Here's my brain dump on the issue, to revive discussion. As you propose, IMO this new feature would use the standard index creation syntax: CREATE [UNIQUE] INDEX someindex ON parted_table (a, b);

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Fri, Oct 6, 2017 at 7:24 PM, Dilip Kumar wrote: > On Fri, Oct 6, 2017 at 6:08 PM, Alexander Kuzmenkov > wrote: >> >>> Analysis: The estimated value of the lossy_pages is way higher than >>> its actual value and reason is that the total_pages

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Oct 6, 2017 at 8:45 PM, Robert Haas wrote: > On Fri, Oct 6, 2017 at 8:40 AM, Ashutosh Bapat > wrote: >> Sorry. I sent a wrong file. Here's the real v37. > > Committed 0001-0006. I made some assorted comment and formatting > changes

Re: [HACKERS] On markers of changed data

Tom, Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Oct 6, 2017 at 11:22 PM, Tom Lane wrote: > > Andrey Borodin writes: > >> Is it safe to use file modification time to track that file were changes > >> since previous backup? >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Oct 6, 2017 at 8:40 AM, Ashutosh Bapat wrote: > Sorry. I sent a wrong file. Here's the real v37. Committed 0001-0006. I made some assorted comment and formatting changes and two small substantive changes: - In try_nestloop_path, bms_free(outerrelids)

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

By the way, I still wonder if there's any way for a new tuple to get inserted in the place where a HOT redirect would be pointing to, and have it be marked as Frozen, where the old redirect contains a non-invalid Xmax. I tried to think of a way for that to happen, but couldn't think of anything.

Re: [HACKERS] Issue with logical replication: MyPgXact->xmin already is valid

On 06.10.2017 15:29, Petr Jelinek wrote: On 06/10/17 12:16, Konstantin Knizhnik wrote: When creating logical replication slots we quite often get the following error: ERROR: cannot build an initial slot snapshot when MyPgXact->xmin already is valid which cause restart of WAL sender. The

Re: [HACKERS] On markers of changed data

Michael Paquier wrote: > The only sane method for Postgres is really to scan the > page header LSNs, and of course you already know that. I hope the idea is not to have to scan every single page in the database, because that would be too slow. It should be possible to build this so that a

Re: [HACKERS] On markers of changed data

On Fri, Oct 6, 2017 at 11:22 PM, Tom Lane wrote: > Andrey Borodin writes: >> Is it safe to use file modification time to track that file were changes >> since previous backup? > > I'd say no: > > 1. You don't know the granularity of the filesystem's

Re: [HACKERS] On markers of changed data

Andrey Borodin writes: > Is it safe to use file modification time to track that file were changes > since previous backup? I'd say no: 1. You don't know the granularity of the filesystem's timestamps, at least not without making unportable assumptions. 2. There's no

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Robert, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > Michael Paquier wrote: > > On Fri, Oct 6, 2017 at 10:18 PM, Alvaro Herrera > > wrote: > > > Wood, Dan wrote: > > >> Yes, I’ve been testing 9.6. I’ll try Alvaro’s patch today. > > >> > > >> I would prefer to

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 10:57 PM, Alvaro Herrera wrote: > Ah, thanks for the tip. I hope the authors of that can do the gruntwork > of researching this problem there, then. I have some stuff using 9.6 extensively, so like Dan I think I'll chime in anyway. Not before

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Fri, Oct 6, 2017 at 7:04 PM, Dilip Kumar wrote: > On Fri, Oct 6, 2017 at 6:36 PM, Robert Haas wrote: >> On Fri, Oct 6, 2017 at 2:12 AM, Dilip Kumar wrote: The performance results look good, but that's a slightly

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Michael Paquier wrote: > On Fri, Oct 6, 2017 at 10:18 PM, Alvaro Herrera > wrote: > > Wood, Dan wrote: > >> Yes, I’ve been testing 9.6. I’ll try Alvaro’s patch today. > >> > >> I would prefer to focus on either latest 9X or 11dev. > > > > I tested my patch on 9.4 and

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Fri, Oct 6, 2017 at 6:08 PM, Alexander Kuzmenkov wrote: > >> Analysis: The estimated value of the lossy_pages is way higher than >> its actual value and reason is that the total_pages calculated by the >> "Mackert and Lohman formula" is not correct. > > > I think

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 10:18 PM, Alvaro Herrera wrote: > Wood, Dan wrote: >> Yes, I’ve been testing 9.6. I’ll try Alvaro’s patch today. >> >> I would prefer to focus on either latest 9X or 11dev. > > I tested my patch on 9.4 and 9.5 today and it seems to close the

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Fri, Oct 6, 2017 at 6:36 PM, Robert Haas wrote: > On Fri, Oct 6, 2017 at 2:12 AM, Dilip Kumar wrote: >>> The performance results look good, but that's a slightly different >>> thing from whether the estimate is accurate. >>> >>> +nbuckets =

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 7:57 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Fri, Oct 6, 2017 at 1:24 AM, Alvaro Herrera >> wrote: >> +/* >> + * Given a tuple, verify whether the given Xmax matches the tuple's Xmin, >> + * taking into

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Wood, Dan wrote: > Yes, I’ve been testing 9.6. I’ll try Alvaro’s patch today. > > I would prefer to focus on either latest 9X or 11dev. I tested my patch on 9.4 and 9.5 today and it seems to close the problem (with the patch, I waited 10x as many iterations as it took for the problem to occur

Re: [HACKERS] parallel worker (PID ) exited with exit code 1

On Fri, Oct 6, 2017 at 8:19 AM, tushar wrote: > I got some few queries after running sqlsmith against PG HEAD , where i am > getting LOG message like - "parallel worker (PID) exited with exit code 1" > > set force_parallel_mode =1; > select >

Re: [HACKERS] parallel worker (PID ) exited with exit code 1

Am Freitag, den 06.10.2017, 17:49 +0530 schrieb tushar: > I got some few queries after running sqlsmith against PG HEAD , where > i > am getting LOG message like - "parallel worker (PID) exited with > exit > code 1" > > set force_parallel_mode =1; > select >

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Fri, Oct 6, 2017 at 2:12 AM, Dilip Kumar wrote: >> The performance results look good, but that's a slightly different >> thing from whether the estimate is accurate. >> >> +nbuckets = tbm_calculate_entires(maxbytes); >> >> entires? > > changed to > + tbm->maxentries

Re: [HACKERS] parallel worker (PID ) exited with exit code 1

On Fri, Oct 6, 2017 at 9:19 PM, tushar wrote: > 2017-10-06 13:15:34.785 BST [5680] LOG: background worker "parallel worker" > (PID 5964) exited with exit code 1 > ERROR: recovery is not in progress > HINT: Recovery control functions can only be executed during

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

Analysis: The estimated value of the lossy_pages is way higher than its actual value and reason is that the total_pages calculated by the "Mackert and Lohman formula" is not correct. I think the problem might be that the total_pages includes cache effects and rescans. For bitmap entries we

Re: [HACKERS] Issue with logical replication: MyPgXact->xmin already is valid

On 06/10/17 12:16, Konstantin Knizhnik wrote: > When creating logical replication slots we quite often get the following > error: > > ERROR:  cannot build an initial slot snapshot when MyPgXact->xmin > already is valid > > which cause restart of WAL sender. > The comment to this line doesn't

[HACKERS] On markers of changed data

Hi, hackers! Currently I'm working on page-level incremental backups using WAL-G codebase[0]. And I have two questions that I cannot resolve myself. Incremental backup is a set of changes, that should be applied over preexisting backup. I use page LSN to understand should page be backup`ed or

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Fri, Oct 6, 2017 at 7:34 PM, Alvaro Herrera wrote: > Just search for "Æsop" in the archives: > https://www.postgresql.org/message-id/CACjxUsPPCbov6DDPnuGpR=fmxhsjsn_mri3rjygvbrmcrff...@mail.gmail.com (laugh) I didn't know this one. -- Michael -- Sent via

[HACKERS] parallel worker (PID ) exited with exit code 1

Hi, I got some few queries after running sqlsmith against PG HEAD , where i am getting LOG message like - "parallel worker (PID) exited with exit code 1" set force_parallel_mode =1;  select   pg_catalog.pg_wal_replay_pause() as c0,   ref_0.ev_type as c1     from  

Re: [HACKERS] [POC] hash partitioning

Hi Amul, On 09/28/2017 05:56 AM, amul sul wrote: It does not really do the partition pruning via constraint exclusion and I don't think anyone is going to use the remainder in the where condition to fetch data and hash partitioning is not meant for that. But I am sure that we could solve this

Re: [HACKERS] parallelize queries containing initplans

On Fri, Oct 6, 2017 at 2:32 AM, Robert Haas wrote: > On Thu, Oct 5, 2017 at 1:16 PM, Amit Kapila wrote: >> On Thu, Oct 5, 2017 at 6:08 PM, Robert Haas wrote: >>> On Thu, Oct 5, 2017 at 5:52 AM, Amit Kapila

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Michael Paquier wrote: > On Fri, Oct 6, 2017 at 1:24 AM, Alvaro Herrera > wrote: > + /* > +* If the xmax of the old tuple is identical to the xmin of the new one, > +* it's a match. > +*/ > + if (xmax == xmin) > + return true; > I would use

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

Michael Paquier wrote: > On Tue, Oct 3, 2017 at 12:54 AM, Alvaro Herrera > wrote: > > I'd argue about this in the same direction I argued about > > BufferGetPage() needing an LSN check that's applied separately: if it's > > too easy for a developer to do the wrong thing

[HACKERS] Issue with logical replication: MyPgXact->xmin already is valid

When creating logical replication slots we quite often get the following error: ERROR: cannot build an initial slot snapshot when MyPgXact->xmin already is valid which cause restart of WAL sender. The comment to this line doesn't clarify much: /* so we don't overwrite the existing

Re: [HACKERS] Still another race condition in recovery TAP tests

On 6 October 2017 at 14:03, Noah Misch wrote: > On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote: >> (I do kinda wonder why we rolled our own RecursiveCopy; surely there's >> a better implementation in CPAN?) > > Fewer people will test as we grow the list of modules

Re: [HACKERS] [PATCH] Tests for reloptions

В письме от 3 октября 2017 11:48:43 пользователь Michael Paquier написал: > > src/backend/access/common/reloptions.c get only 7 lines, it was quite > > covered by existing test, but all most of the access methods gets some > > coverage increase: > > > > src/backend/access/brin 1268 ->

Re: [HACKERS] search path security issue?

On Fri, Oct 6, 2017 at 12:05 AM, Joshua D. Drake wrote: > On 10/05/2017 02:54 PM, David G. Johnston wrote: > >> On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake > >wrote: >> >> I get being able to change my

Re: [HACKERS] pgsql: Remove ICU tests from default run

On Sat, Mar 25, 2017 at 04:30:45AM +, Peter Eisentraut wrote: > Remove ICU tests from default run > > These tests require the test database to be in UTF8 encoding. Until > there is a better solution, take them out of the default test set and > treat them like the existing collate.linux.utf8

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Fri, Oct 6, 2017 at 1:24 AM, Alvaro Herrera wrote: > I think this is the patch for 9.3. I ran the test a few hundred times > (with some additional changes such as randomly having an update inside a > savepoint that's randomly aborted, randomly aborting the

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

On 2017/10/05 20:06, Kyotaro HORIGUCHI wrote: Since WCO ensures finally inserted values, we can't do other than acturally requesting for the values. I think so too. So just merging WCO columns to RETURNING in deparsed query is ok. But can't we concatenate returningList and

Re: [HACKERS] Comment typo

On 2017/10/05 21:48, Robert Haas wrote: On Thu, Oct 5, 2017 at 6:11 AM, Etsuro Fujita wrote: Here is a small patch to fix a typo in a comment in partition.c: s/mantain/maintain/. Committed. Thanks! Best regards, Etsuro Fujita -- Sent via pgsql-hackers

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Oct 4, 2017 at 9:04 PM, Robert Haas wrote: > On Tue, Oct 3, 2017 at 3:27 PM, Robert Haas wrote: >> I decided to skip over 0001 for today and spend some time looking at >> 0002-0006. > > Back to 0001. > > +Enables or disables the query

Re: [HACKERS] Parallel Append implementation

On 6 October 2017 at 08:49, Amit Kapila wrote: > On Thu, Oct 5, 2017 at 4:11 PM, Amit Khandekar wrote: >> >> Ok. How about removing pa_all_partial_subpaths altogether , and >> instead of the below condition : >> >> /* >> * If all the child rels

Re: [HACKERS] Still another race condition in recovery TAP tests

On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote: > (I do kinda wonder why we rolled our own RecursiveCopy; surely there's > a better implementation in CPAN?) Fewer people will test as we grow the list of modules they must first install. Bundling a copy is tempting, but most CPAN modules

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Thu, Oct 5, 2017 at 8:15 PM, Robert Haas wrote: > On Sun, Sep 17, 2017 at 7:04 AM, Dilip Kumar wrote: >> I used lossy_pages = max(0, total_pages - maxentries / 2). as >> suggesed by Alexander. > > Does that formula accurately estimate the number