On Fri, Mar 24, 2017 at 11:49 PM, Pavan Deolasee
wrote:
>
>
> On Fri, Mar 24, 2017 at 6:46 PM, Amit Kapila
> wrote:
>>
>>
>>
>> I was worried for the case if the index is created non-default
>> collation, will the datumIsEqual() suffice the need. Now a
ndex.
I think saying ".. last page in hash index" sounds slightly awkward as
this is the last page for current split point, how about just
"Initialize the page. ..."
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hacker
On Thu, Mar 23, 2017 at 11:24 PM, Ashutosh Sharma wrote:
> Hi,
>
> On Tue, Feb 7, 2017 at 9:23 AM, Robert Haas wrote:
>> On Mon, Feb 6, 2017 at 10:40 PM, Amit Kapila wrote:
>>>> Maybe we should call them "unused pages".
>>>
>>> +1. If we
with force_parallel_mode=regress and all the test are
> passing.
>
Thomas, did you get chance to verify Dilip's latest patch?
I have added this issue in PostgreSQL 10 Open Items list so that we
don't loose track of this issue.
--
With Regards,
Amit Kapila.
EnterpriseDB: http:
tion. I have added this to open items list.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 23, 2017 at 3:54 PM, Pavan Deolasee
wrote:
> Thanks Amit. v19 addresses some of the comments below.
>
> On Thu, Mar 23, 2017 at 10:28 AM, Amit Kapila
> wrote:
>>
>> On Wed, Mar 22, 2017 at 4:06 PM, Amit Kapila
>> wrote:
>> > On Tue,
On Fri, Mar 24, 2017 at 12:25 AM, Pavan Deolasee
wrote:
>
>
> On Thu, Mar 23, 2017 at 7:53 PM, Amit Kapila
> wrote:
>>
>> >
>>
>> I am not sure on what basis user can set such parameters, it will be
>> quite difficult to tune those parameters. I thi
ched wrong patch. Here are the correct
> set of patches.
>
The latest version of patches looks fine to me.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
ks, this version looks good to me.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 23, 2017 at 4:26 PM, Ashutosh Sharma wrote:
> On Thu, Mar 23, 2017 at 9:17 AM, Amit Kapila wrote:
>>
>> On Thu, Mar 23, 2017 at 8:43 AM, Amit Kapila wrote:
>> >
>> > I think this will work, but not sure if there is a merit to deviate
>> >
HASHO_PAGE_ID)
ereport(ERROR,
spurious white space.
>
> Also, I have attached
> '0001-Mark-freed-overflow-page-as-UNUSED-pagetype-v2.patch' that
> handles your comment mentioned in [1].
>
In general, we have to initialize prevblock with max_bucket, but here
i
On Thu, Mar 23, 2017 at 3:44 PM, Pavan Deolasee
wrote:
> On Wed, Mar 22, 2017 at 4:06 PM, Amit Kapila
> wrote:
>>
>
>> 3.
>> + /*
>> + * HASH indexes compute a hash value of the key and store that in the
>> + * index. So
>> we must first obtain the ha
() check in master code as well and then you
will most probably again see the same regression. Also, I think if we
test at fillfactor 80 or 75 (which is not unrealistic considering an
update-intensive workload), then we might again see regression.
--
With Regards,
Amit Kapila.
EnterpriseDB: ht
n be given for both of them as
>> from user perspective there is not much difference between both the
>> messages?
>
> I think we should show separate message because they are two different
> type of pages. In the sense like, one is initialised whereas other is
> complete
On Wed, Mar 22, 2017 at 4:06 PM, Amit Kapila wrote:
> On Tue, Mar 21, 2017 at 6:47 PM, Pavan Deolasee
> wrote:
>>
>>>
>>
>> Please find attached rebased patches.
>>
>
> Few comments on 0005_warm_updates_v18.patch:
>
Few more comments on 0
On Thu, Mar 23, 2017 at 8:43 AM, Amit Kapila wrote:
> On Wed, Mar 22, 2017 at 3:39 PM, Ashutosh Sharma
> wrote:
>> Hi,
>>
>> On Wed, Mar 22, 2017 at 8:41 AM, Amit Kapila wrote:
>>
>> To fix this, I think we should pass 'REGBUF_KEEP_DATA' while
On Wed, Mar 22, 2017 at 3:39 PM, Ashutosh Sharma wrote:
> Hi,
>
> On Wed, Mar 22, 2017 at 8:41 AM, Amit Kapila wrote:
>
> To fix this, I think we should pass 'REGBUF_KEEP_DATA' while
> registering the buffer. Something like this,
>
> -
,
+ errmsg("index table contains empty page")));
Do we want to give a separate message for EMPTY and NEW pages? Isn't
it better that the same error message can be given for both of them as
from user perspective there is not much difference between both the
messages?
--
With
xed. As Ashutosh referred, I added a very
>> simple suggestion to use Windows Group Policy tool.
>
>
> Amit, Magnus, you are signed up as reviewers for this patch. Do you know
> when you'll have a chance to take a look?
>
I have provided my feedback and I could not test it on
ted the table, we have exactly
typo.
/inserted the table/inserted in the table
14.
+ lp [1] [2]
+ [, ]->[111, ]
Here, after the update, the first column should be .
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
possible cases. It seems this is to save
database from getting corrupt or behaving insanely if due to some
reason (like a coding error or others) the check fails.
In a quick look, I don't find any other divergence in both the
function, is there any other divergence in both functions, if so, I
l the rows is
> particularly unrealistic. Sure, it's not everything, but it's
> something. Now, I would agree that all of that PLUS unlogged tables
> with fsync=off is not too realistic. What kind of regression would we
> observe if we eliminated those last two variables?
On Mon, Mar 20, 2017 at 8:27 AM, Robert Haas wrote:
> On Fri, Mar 17, 2017 at 2:30 AM, Amit Kapila wrote:
>>> I was wondering about doing an explicit test: if the XID being
>>> committed matches the one in the PGPROC, and nsubxids matches, and the
>>> actual list o
f scan key push down
work [1].
[1] - https://commitfest.postgresql.org/12/850/
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s found, and one for "all of these" (for WARM,
> indirect indexes) which needs to be checked to completion.
>
How will that help to mitigate the regression? I think what might
help here is if we fetch the required columns for WARM only when we
know hot_update is false.
--
With
ee any value in treating the last page allocated during
_hash_alloc_buckets() any different from other pages which are prior
to that but will get allocated when required.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n xlog XLOG_HASH_VACUUM_ONE_PAGE and then using
different block_id for fetching those items in
hash_xlog_vacuum_get_latestRemovedXid(). So probably matching those
will fix this issue (instead of fetching block number and items from
block_id 1, we should use block_id 0).
--
With Regards,
Amit
On Tue, Mar 21, 2017 at 8:16 AM, Amit Kapila wrote:
> On Mon, Mar 20, 2017 at 8:58 PM, Mithun Cy wrote:
>> Hi Amit, Thanks for the review,
>>
>> On Mon, Mar 20, 2017 at 5:17 PM, Amit Kapila wrote:
>>> idea could be to make hashm_spares a two-dimensional array
>
On Mon, Mar 20, 2017 at 8:58 PM, Mithun Cy wrote:
> Hi Amit, Thanks for the review,
>
> On Mon, Mar 20, 2017 at 5:17 PM, Amit Kapila wrote:
>> idea could be to make hashm_spares a two-dimensional array
>> hashm_spares[32][4] where the first dimension will indicate the spli
slots, we
+ * distribute the buckets equally among them. So we allocate only one
+ * forth of total buckets in new splitpoint group at time to consume
+ * one phase after another.
spelling.
/forth/fourth
/at time/at a time
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Sat, Mar 18, 2017 at 5:13 PM, Ashutosh Sharma wrote:
> On Sat, Mar 18, 2017 at 1:34 PM, Amit Kapila wrote:
>> On Sat, Mar 18, 2017 at 12:12 AM, Ashutosh Sharma
>> wrote:
>>> On Fri, Mar 17, 2017 at 10:54 PM, Jeff Janes wrote:
>>>> While trying to f
On Fri, Mar 17, 2017 at 8:34 PM, Ashutosh Sharma wrote:
> On Fri, Mar 17, 2017 at 6:13 PM, Amit Kapila wrote:
>> On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma
>> wrote:
>>> On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila
>>> wrote:
>>>
>>>
nk that it can be a newly allocated page?
Basically, we always initialize the special space of newly allocated
page, so not sure what makes you deduce that it can be newly allocated
page.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to initialize the special
space in this case (free overflow page). I think we can mark such a
page type as LH_UNUSED_PAGE and then initialize the other fields of
special space. Nonetheless, I think we still need modifications in
hashfuncs.c so that it can understand this type of page.
--
With Rega
On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma wrote:
> On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila wrote:
>
> As I said in my previous e-mail, I think you need
>> to record clearing of this flag in WAL record XLOG_HASH_DELETE as you
>> are not doing this unconditio
On Fri, Mar 17, 2017 at 12:30 PM, Ashutosh Sharma wrote:
> On Fri, Mar 17, 2017 at 9:03 AM, Amit Kapila wrote:
>> On Thu, Mar 16, 2017 at 1:15 PM, Ashutosh Sharma
>> wrote:
>>> Hi,
>>>
>>> Attached is the patch that allows WAL consistency tool to mask
On Sun, Mar 12, 2017 at 8:11 AM, Robert Haas wrote:
> On Fri, Mar 10, 2017 at 7:39 PM, Amit Kapila wrote:
>> I agree that more analysis can help us to decide if we can use subxids
>> from PGPROC and if so under what conditions. Have you considered the
>> another patch I h
already
> tested it using Kuntal's WAL consistency tool and it works fine.
>
+ * unlogged. So, mask it. See _hash_kill_items(), MarkBufferDirtyHint()
+ * for
details.
+ */
I think in above comment, a reference to _hash_kill_items is
sufficient. Other than that patch looks okay.
--
hange the comment in
hashbucketcleanup. As I said in my previous e-mail, I think you need
to record clearing of this flag in WAL record XLOG_HASH_DELETE as you
are not doing this unconditionally and then during replay clear it
only when the WAL record indicates the same.
--
With Regards,
Am
On Thu, Mar 16, 2017 at 1:02 PM, Ashutosh Sharma wrote:
> On Thu, Mar 16, 2017 at 11:11 AM, Amit Kapila wrote:
>> On Wed, Mar 15, 2017 at 9:23 PM, Ashutosh Sharma
>> wrote:
>>>
>>>>
>>>> Few other comments:
>>>> 1.
>>>>
andbyReleaseLockTree(xid, parsed->nsubxacts, parsed->subxacts);
The patch uses XACT_XINFO_HAS_AE_LOCKS during abort replay, but during
normal operation (XactLogAbortRecord()), it doesn't seem to log the
information. Is this an oversight or do you have some reason for
doing so?
--
estampTz abort_time,
if (xl_xinfo.xinfo &
XACT_XINFO_HAS_TWOPHASE)
XLogRegisterData((char *) (&xl_twophase), sizeof
(xl_xact_twophase));
+ if (CurrentTransactionState->didLogAELock)
+ xl_xinfo.xinfo |=
XACT_XINFO_HAS_AE_LOCKS;
You need to set xl_info before the below line in XactLogAbortRecord()
to
y reasons?
>
> That's because we conditionally WAL Log this flag status and when we
> do so, we take a it's FPI.
>
Sure, but we are not clearing in conditionally. I am not sure, how
after recovery it will be cleared it gets set during normal operation.
Moreover, b
d by
using RBM_ZERO_AND_LOCK mode. I think we can change it so that it
forces a new allocation (if the block doesn't exist) on need. I agree
this is somewhat more change than what you have proposed to circumvent
the sparse file behavior, but may not be a ton more work if we decide
to
On Thu, Mar 9, 2017 at 10:21 PM, Masahiko Sawada wrote:
> On Wed, Mar 8, 2017 at 1:43 AM, Peter Geoghegan wrote:
>> On Sat, Mar 4, 2017 at 1:30 AM, Amit Kapila wrote:
>>>> While I can't see this explained anywhere, I'm
>>>> pretty sure that that&#x
a split, we'll
+ * fail to find it and do nothing (this is not an
error case --- we assume
+ * the item will eventually get marked in a future indexscan).
+ */
+void
+_hash_kill_items(IndexScanDesc scan)
I think this comment doesn't make much sense for hash index because
item won't
On Tue, Mar 14, 2017 at 9:59 PM, Robert Haas wrote:
> On Tue, Jan 17, 2017 at 11:49 AM, Robert Haas wrote:
>> On Mon, Jan 16, 2017 at 7:23 AM, Amit Kapila wrote:
>>>
>>>
>>> Isn't it better to call clamp_row_est in join costing functions as we
>>&g
disk-space anyway.
>
> We wouldn't attempt to use the area of the file which is not yet
> allocated except when doing a bucket split?
>
That's right.
> If that's the case then
> this does seem to at least be less of an issue, though I hope we put in
> appropriate co
On Tue, Mar 14, 2017 at 10:59 PM, Robert Haas wrote:
> On Mon, Mar 13, 2017 at 11:48 PM, Amit Kapila wrote:
>> We didn't found any issue with the above testing.
>
> Great! I've committed the latest version of the patch, with some
> cosmetic changes.
>
Thanks
As pointed out by Tom [1], attached is a patch to remove obsolete text
from src/backend/access/hash/README
[1] - https://www.postgresql.org/message-id/5515.1489514099%40sss.pgh.pa.us
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
fix_hash_index_readme_v1.patch
On Fri, Feb 10, 2017 at 4:34 PM, Amit Kapila wrote:
>
> I could see two possibilities to determine whether the plan (for which
> we are going to generate an initplan) contains a reference to a
> correlated var param node. One is to write a plan or path walker to
> determine any
On Mon, Mar 13, 2017 at 6:26 PM, Amit Kapila wrote:
> On Thu, Mar 9, 2017 at 3:11 AM, Robert Haas wrote:
>> On Tue, Mar 7, 2017 at 6:41 PM, Robert Haas wrote:
>>>>> Great, thanks. 0001 looks good to me now, so committed.
>>>>
>>>> Committed 000
On Wed, Mar 8, 2017 at 6:58 PM, Robert Haas wrote:
> On Wed, Mar 8, 2017 at 7:04 AM, Amit Kapila wrote:
>> On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas wrote:
>>> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila wrote:
>>>> I think it can give us benefit in
>>&g
On Sun, Mar 12, 2017 at 8:06 AM, Robert Haas wrote:
> On Sat, Mar 11, 2017 at 12:20 AM, Amit Kapila wrote:
>>> /*
>>> + * Change the shared buffer state in critical section,
>>> + * otherwise any error cou
the master. Maybe
> you've already tried something like that?
>
I also think so and apart from that I think it makes sense to perform
recovery test by Jeff Janes tool and probably tests with
wal_consistency_check. These tests are already running from past seven
hours or so and I wi
vidual
tuples as well instead of a complete page, however not sure if there
is any benefit for doing the same because XLogRecordAssemble() will
anyway remove the empty space from the page. Let me know if you have
something else in mind.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://
On Sat, Mar 11, 2017 at 2:10 AM, Robert Haas wrote:
> On Fri, Mar 10, 2017 at 6:25 AM, Amit Kapila wrote:
>> On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane wrote:
>>> Amit Kapila writes:
>>>> Just to let you know that I think I have figured out the reason o
On Fri, Mar 10, 2017 at 6:21 PM, Robert Haas wrote:
> On Fri, Mar 10, 2017 at 7:08 AM, Amit Kapila wrote:
>> On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas wrote:
>>> On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila wrote:
>>>> Do we really need to set LSN on this
On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila wrote:
>> Do we really need to set LSN on this page (or mark it dirty), if so
>> why? Are you worried about restoration of FPI or something else?
>
> I haven't thought t
On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane wrote:
> Amit Kapila writes:
>> Just to let you know that I think I have figured out the reason of
>> failure. If we run the regressions with attached patch, it will make
>> the regression tests fail consistently in same way. Th
On Fri, Mar 10, 2017 at 11:43 AM, Amit Kapila wrote:
> On Fri, Mar 10, 2017 at 10:51 AM, Tom Lane wrote:
>>
>> Also, I see clam reported in green just now, so it's not 100%
>> reproducible :-(
>>
>
> Just to let you know that I think I have figured out t
the fact that the status update for transaction
involves subtransactions and then we can use xidcache for actually
processing the status update. Second is advertise all the
subtransaction ids for which status needs to be update, but I am sure
that is not-at all efficient as that will co
On Thu, Mar 9, 2017 at 11:15 PM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 10:23 AM, Amit Kapila wrote:
>> Right, if we use XLogReadBufferForRedoExtended() instead of
>> XLogReadBufferExtended()/LockBufferForCleanup during relay routine,
>> then it will restore FPI when r
00%3A01
>
Will look into this, though I don't have access to that machine, but
it looks to be a power machine and I have access to somewhat similar
machine.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Thu, Mar 9, 2017 at 12:25 AM, Robert Haas wrote:
> On Wed, Mar 8, 2017 at 7:45 AM, Amit Kapila wrote:
>> Okay, I can try, but note that currently there is no test related to
>> "snapshot too old" for any other indexes.
>
> Wow, that's surprising. It
h normal operation"
>
> It seems like a good test to do with this patch would be to set up a
> pgbench test on the master with a hash index replacing the usual btree
> index. Then, set up a standby and run a read-only pgbench on the
> standby while a read-write pgbench
r state in a critical
section, otherwise any error could make the page unrecoverable."
> Maybe this could get some tests, via the isolation tester, for things
> like snapshot too old?
>
Okay, I can try, but note that currently there is no test related to
"snapshot too old" for any other indexes.
> I haven't gone through all of this in detail yet; I think most of it
> is right on target. But there is a lot more to look at yet.
>
Thanks for your valuable comments.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila wrote:
>
>> I think it can give us benefit in
>> such cases as well (especially when we have to discard rows based heap
>> rows). Now, consider it from another viewpoint, wha
ting the scan if it is not already initialized.
There is an additional check required for ensuring if index runtime
keys are ready before calling index_rescan. Attached patch fixes the
problem.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
fix_scandesc_initializati
On Tue, Mar 7, 2017 at 9:16 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 9:09 PM, Amit Kapila wrote:
>> Sure, if you think both Writes and Reads at OS level can have some
>> chance of blocking in obscure cases, then we should add a wait event
>> for them.
>
> I th
On Tue, Mar 7, 2017 at 10:12 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila wrote:
>> I also think that commit didn't intend to change the behavior,
>> however, the point is how sensible is it to keep such behavior after
>> Parallel Append. I
On Wed, Mar 8, 2017 at 3:38 AM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 4:18 AM, Robert Haas wrote:
>> On Tue, Feb 28, 2017 at 7:31 PM, Amit Kapila wrote:
>>> Yeah, actually those were added later in Enable-WAL-for-Hash* patch,
>>> but I think as this patch is s
On Tue, Mar 7, 2017 at 8:02 AM, David Rowley
wrote:
> On 7 March 2017 at 15:21, Amit Kapila wrote:
>> +1. How about changing the description of
>> max_parallel_workers_per_gather to "taken from max_worker_processes,
>> limited by max_parallel_workers"?
>
&g
that is not even related to the problem being discussed?
>>
>
> I think he has changed to allow parallelism for inheritance or partition
> tables. For normal tables, it won't be touched until the below if-condition
> is satisfied.
>
> if (heap_pages < (BlockNumber) min_parallel_tab
On Tue, Mar 7, 2017 at 3:24 AM, Robert Haas wrote:
> On Sun, Mar 5, 2017 at 9:41 PM, Amit Kapila wrote:
>>> RCA:
>>>
>>> From "Replace min_parallel_relation_size with two new GUCs" commit
>>> onwards, we are not assigning parallel workers
he description of
max_parallel_workers_per_gather to "taken from max_worker_processes,
limited by max_parallel_workers"?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
n with this patch applied,
> using a scale factor greater than shared_buffers, and generate a wait
> event profile, just to see if these are showing up and how often.
>
Yeah, that makes sense to me and we should try for both read-write and
read-only tests.
--
With Regards,
Amit
ry will work in the
>> > !EXEC_BACKEND case. I confirmed that the behavior is ensured also
>> > in EXEC_BACKEND case.
>
> But this doesn't work for
> LWLockNewTrancheId/LWLockRegisterTranche and it is valuable
> interface. So the measure we can take is redefining
On Mon, Mar 6, 2017 at 6:49 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote:
>
> I was going to do it after index and index-only scans and parallel
> bitmap heap scan were committed, but I've been holding off on
> committing parallel bitmap heap sca
On Mon, Mar 6, 2017 at 4:57 PM, Michael Banck wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 08:14:28AM +0530, Amit Kapila wrote:
>> On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote:
>> > On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote:
>> >> On Wed,
one of
them is big enough to allow parallel workers. Now in this case, with
your proposed fix it will try to scan all the partitions in parallel
workers which I think can easily result in bad performance. I think
the right way to make such plans parallel is by using Parallel Append
node (h
ileSync(src->vfd, WAIT_EVENT_SYNC_REWRITE_DATA_BLOCK) != 0)
Do we want to consider recording wait event for both write and sync?
It seems to me OS level writes are relatively cheap and sync calls are
expensive, so shouldn't we just log for sync calls? I could see the
similar usage at
On Sat, Mar 4, 2017 at 2:29 PM, Robert Haas wrote:
> On Fri, Mar 3, 2017 at 9:44 AM, Amit Kapila wrote:
>> On Tue, Feb 28, 2017 at 11:06 AM, Kuntal Ghosh
>> wrote:
>>> Hello everyone,
>>>
>>> I've attached a patch which implements WAL consistency
On Sat, Mar 4, 2017 at 8:55 AM, Peter Geoghegan wrote:
> On Fri, Mar 3, 2017 at 6:58 PM, Amit Kapila wrote:
>> You are right that we don't want the number of unclaimed-by-FSM
>> recyclable pages to grow forever, but I think that won't happen with
>> this pa
(ID range check in LWLockInitialize would be
> useless if it is not used by extensions)
>
What exact problem are you referring here?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
this patch. As soon as there are more deletions (in heap), in the
next vacuum cycle, the pages will be reclaimed by lazy_vacuum_index().
> (Thinks about it some more...)
>
> Unfortunately, I just saw a whole new problem with this patch:
> _bt_page_recyclable() is the one place in the B-
ow location:
https://www.postgresql.org/docs/devel/static/xfunc-c.html#idp86986416
Alternatively, you can check the commit
c1772ad9225641c921545b35c84ee478c326b95e to see how it is used in
pg_stat_statements.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
-
ccordingly.
Comment referring to btree is wrong, you need to refer hash.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
re it's no good to take locks before
> recovery reaches a consistent state.
So we should move this loading of blocks once the recovery reaches a
consistent state so that we can connect to a database. To allow
worker, to take a lock, we need to dump relation oid as well. Is that
what you are e
On Thu, Mar 2, 2017 at 3:50 PM, Robert Haas wrote:
> On Tue, Feb 28, 2017 at 5:25 PM, Amit Kapila wrote:
>> When such a function (that contains statements which have parallel
>> plans) is being executed as part of another parallel plan, it can
>> allow spawning workers un
other lock release calls
which are called at every commit, so probably this is okay.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 1, 2017 at 11:24 AM, Dilip Kumar wrote:
> On Wed, Mar 1, 2017 at 11:13 AM, Amit Kapila wrote:
>> I think for now we can keep the parallel safety check for cheapest
>> inner path, though it will be of use only for the very first time we
>> compare the paths in
On Tue, Feb 28, 2017 at 9:28 PM, Dilip Kumar wrote:
> On Mon, Feb 27, 2017 at 10:27 AM, Amit Kapila wrote:
>> Okay, but in that case don't you think it is better to consider the
>> parallel safety of cheapest_total_inner only when we don't find any
>> cheap para
On Tue, Feb 28, 2017 at 11:52 PM, Stephen Frost wrote:
> Greetings!
>
> The PostgreSQL committers would like to welcome Andrew Gierth as a new
> committer for the PostgreSQL project.
>
Congratulations!
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
On Mon, Feb 27, 2017 at 12:21 PM, Robert Haas wrote:
> On Mon, Feb 27, 2017 at 8:33 AM, Amit Kapila wrote:
>> Is there any easy way to find out which way is less expensive?
>
> No. But that's a separate problem. I'm just saying we shouldn't
> arbitrarily prohi
ested, particularly
> in xlog replay code. I am leaning toward (2). Other opinions?
>
Your Approach-2 patch looks like a sane idea to me, if we decide to do
it some other way, I can write a patch unless you prefer to do it by
yourself.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Feb 26, 2017 at 12:01 PM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 3:54 PM, Amit Kapila wrote:
>> I agree in some cases it could be better, but I think benefits are not
>> completely clear, so probably we can leave it as of now and if later
>> any one comes wit
On Sun, Feb 26, 2017 at 4:14 PM, Robert Haas wrote:
> On Sun, Feb 26, 2017 at 6:34 AM, Amit Kapila wrote:
>> On Sat, Feb 25, 2017 at 9:47 PM, Dilip Kumar wrote:
>>> On Sat, Feb 25, 2017 at 5:12 PM, Amit Kapila
>>> wrote:
>>>> Sure, but that should only h
On Sun, Feb 26, 2017 at 11:15 PM, Robert Haas wrote:
> On Mon, Feb 20, 2017 at 7:52 AM, Amit Kapila wrote:
>
>> The main point is if we
>> keep any loose end in this area, then there is a chance that the
>> regression test select_parallel can still fail, if not now, the
On Thu, Feb 16, 2017 at 6:43 PM, Anastasia Lubennikova
wrote:
> 14.02.2017 15:46, Amit Kapila:
>
>
>> 4.
>> + IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P
>> INCLUDE
>>INCLUDING INCREMENT INDEX INDEXES INHERIT INHERITS INITIALLY INL
401 - 500 of 3368 matches
Mail list logo
